cloud Function logging isn't working outside of the test scope anymore

[tsuf239]

I tried this:

run examples/tests/sdk_tests/function/logging.w

This happened:

logged:

hello world
hello world

only logs in the test scope

I expected this:

should log:

hello world
log inside f1
log inside f2
log inside f1
hello world
log inside f1
log inside f2
log inside f1

logs in any scope

Is there a workaround?

No response

Component

SDK

Wing Version

No response

Node.js Version

No response

Platform(s)

No response

Anything else?

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

[Chriscbr]

I can imagine how one might want to aggregate all of the logs from different functions that were "spawned" from a test... but I'm not sure it's clear what are the underlying rules for what logs are shown. For example:

bring cloud;
bring util;

let processor = new cloud.Function(inflight (m: str) => {
  log("processing: ${m}");
  counter.inc();
});

let queue = new cloud.Queue();
queue.setConsumer(inflight (m: str) => {
  processor.invoke(m);
});

let pusher = new cloud.Function(inflight (m: str) => {
  log("pushing: ${m}");
  queue.push(m);
});

let schedule = new cloud.Schedule(rate: 5s);
schedule.onTick(inflight () => {
  pusher.invoke("bloop");
});

test "message is processed" {
  pusher.invoke("floop");
  util.sleep(10s);
  assert(counter.peek() > 0);
  log("success!");
};

Here I have a made-up app with a test at the end. The test pushes a message to a queue, and checks that a counter was incremented. There are also some ongoing events that will be happening unrelated to test (for example, cloud.Schedule pushes a message "bloop" to the queue every 5 seconds). This app is leveraging the distributed nature of the cloud - even though pushing to queue causes processor to be invoked, there might not necessarily be a single request ID that which connects the events together. What logs would make sense to be printed from this example?

a) "success!"
b) "pushing: floop", "success!"
c) "pushing: floop", "processing: floop", "success!"
d) "pushing: bloop", "processing: bloop", "pushing: floop", "processing: floop", "success!"

More logs is usually better, but I could also imagine it being confusing to see unrelated logs mixed in with your test logs. It's sort of like if you create a child process in your computer, you may have to decide whether to inherit its STDIN/STDOUT or not. (except in the cloud, not all processes have parents? 🤔) @tsuf239 I'm curious if you have any thoughts

[tsuf239]

I believe that the cloud targets should behave like the sim
(and it may not be such a hard thing to implement if we declare a log group at the start of the run of the app, and make sure to log everything there (then filter out aws meta logs))
I run this on the sim and this is the output:

pass ┌ logging.wsim » root/env0/test:message is processed
          │ pushing: floop
          │ processing: floop
          └ success!

What we can do in the future, when people start to have too many logs, is to specify the resource name:

pass ┌ logging.wsim » root/env0/test:message is processed
          │ pusher:
                  pushing: floop
          │ schedule:
                  processing: floop
          └ test:
                  success!

Ordered by the timestamp,
This can be a really cool feature of the preview environment too- we can store/pass more information per line (location in wing code, scope, etc... )

[github-actions]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days.
Feel free to re-open this issue when there's an update or relevant information to be added.
Thanks!

[github-actions]

Hi,

This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days.
Feel free to re-open this issue when there's an update or relevant information to be added.
Thanks!

[staycoolcall911]

This works now Wing 0.51.26.
Closing.