Wait for submission result

maleszka commented

2026-03-22 22:20:41 +01:00

Owner

Research needed. Ideas:

wbij starts a background process that asks PlatformAPI on repeat for the status
it should be detached from main cache; so that other wbij commands can be run
after finishing, wbij can still read to the same stdout (?)
desktop notification when finished?
play a user-provided sound when finished? or just a user-provided cmd hook?

How much should wbij be obtrusive when it get's the status? Should it try to get the control over terminal? Or only print one-line message?

Research needed. Ideas: - wbij starts a background process that asks PlatformAPI on repeat for the status - it should be detached from main cache; so that other wbij commands can be run - after finishing, wbij can still read to the same stdout (?) - desktop notification when finished? - play a user-provided sound when finished? or just a user-provided cmd hook? How much should wbij be obtrusive when it get's the status? Should it try to get the control over terminal? Or only print one-line message?

maleszka referenced this issue

2026-04-07 22:41:06 +02:00

Post-submit hook, launching browser automatically #7

maleszka added the

question

label

2026-04-09 17:29:18 +02:00

kbity commented

2026-08-11 20:57:52 +02:00

Collaborator

How much should wbij be obtrusive when it get's the status? Should it try to get the control over terminal? Or only print one-line message?

Assuming wbij forks into the background and passes control of the shell back to the user, I would suggest it doesn't intrude at all -- I can see myself in the future being annoyed by having my outputs mangled. Instead I suggest a mode of operation as follows:

user runs wbij submit (...)
submission view URL is retrieved
user-defined hook is run with aforementioned URL
wbij forks into the background, waiting for submission result
in the foreground a waiting message is displayed; now the user can either:
- kill the foreground process and continue working
- wait for the verdict
when the child process receives results:
- if the parent is still alive, we (somehow?) send information to it and display a neat summary, then exit
- otherwise, we run another user-defined hook (maybe some desktop notification by default, as you suggested?)

This way, we can return uninterrupted control of the shell back to the user if they so desire.

(nb. this is similar to how SiO2 operates during the POI final stage, where you can either keep working and wait for the judge notification, or switch focus to the browser and keep refreshing until the result pops up)

> How much should wbij be obtrusive when it get's the status? Should it try to get the control over terminal? Or only print one-line message? Assuming wbij forks into the background and passes control of the shell back to the user, I would suggest it doesn't intrude *at all* -- I can see myself in the future being annoyed by having my outputs mangled. Instead I suggest a mode of operation as follows: - user runs `wbij submit (...)` - submission view URL is retrieved - user-defined hook is run with aforementioned URL - wbij forks into the background, waiting for submission result - in the foreground a waiting message is displayed; now the user can either: - kill the foreground process and continue working - wait for the verdict - when the child process receives results: - if the parent is still alive, we (somehow?) send information to it and display a neat summary, then exit - otherwise, we run another user-defined hook (maybe some desktop notification by default, as you suggested?) This way, we can return uninterrupted control of the shell back to the user if they so desire. (nb. this is similar to how SiO2 operates during the POI final stage, where you can either keep working and wait for the judge notification, or switch focus to the browser and keep refreshing until the result pops up)

👍 1

kbity self-assigned this

2026-08-14 21:00:20 +02:00

kbity referenced this issue

2026-08-14 22:00:45 +02:00

Post-submit hook, launching browser automatically #7

maleszka commented

2026-08-18 13:48:29 +02:00

Author

Owner

Fully agree. Good idea that there should be two hooks: just after submitting and after receiving submission results.

So... you want to std.process.fork and then exit(0) straight afterwards in the parent process, and then continue waiting for full submission results in the child process, right? From the child process, we can still write to the same stdout, as long as we have the same fd (and we do).

But once the child process forks, how do you handle the case when the interactive terminal is closed? In standard case, closing terminal kills all subprocesses (through SIGHUP), including our wbij child process. We can create a new session with setsid() to detach completely from terminal session, so that wbij child is not killed. But, after terminal is closed, writing to stdout can result in EIO (I/O error) and we need to handle this explicitly.

Do you create a new session with setsid() to detach completely from terminal session, so that wbij child process is not killed, or do you do something else? How do you detect that terminal was closed?

I'm curious to see your results! : )

Fully agree. Good idea that there should be two hooks: just after submitting and after receiving submission results. So... you want to `std.process.fork` and then `exit(0)` straight afterwards in the parent process, and then continue waiting for full submission results in the child process, right? From the child process, we can still write to the same `stdout`, as long as we have the same fd (and we do). But once the child process forks, how do you handle the case when the interactive terminal is closed? In standard case, closing terminal kills all subprocesses (through `SIGHUP`), including our wbij child process. We can create a new session with `setsid()` to detach completely from terminal session, so that `wbij` child is not killed. But, after terminal is closed, writing to stdout can result in `EIO` (I/O error) and we need to handle this explicitly. Do you create a new session with `setsid()` to detach completely from terminal session, so that `wbij` child process is not killed, or do you do something else? How do you detect that terminal was closed? I'm curious to see your results! : )

kbity commented

2026-08-18 14:20:46 +02:00

Collaborator

So... you want to std.process.fork and then exit(0) straight afterwards in the parent process, and then continue waiting for full submission results in the child process, right? From the child process, we can still write to the same stdout, as long as we have the same fd (and we do).

Not really, while I do want to wait for the submission results in the background, I also want the foreground process to keep the interactive terminal occupied until the verdict is ready. The intention is that only the foreground will write to stdout, so that if the user sends ^C they can get back to work, and will (at least in the original intention) receive a desktop notification with a short summary, if they configure the second hook to do so.

Do you create a new session with setsid() to detach completely from terminal session, so that wbij child process is not killed, or do you do something else? How do you detect that terminal was closed?

Yup, exactly!
Right now the way I do this is: the parent and child processes have a pipe open, so that the child process can transfer the verdict to the parent and later display it. We can detect if the parent is dead if it closes the reading end of the pipe, which will make std.posix.write return error.BrokenPipe; if this happens the child process will just run the post-result hook and exit.

There is an issue though, as std.posix.errno just does not compile in zig 0.15.2, from which it follows that std.posix.setsid is unusable; this means that the full functionality is blocked by #13.

I'm curious to see your results! : )

I'm just about to start committing parts of the code I've written over the past few days; for now it's all still WIP but expect a PR from kbity:feature/post-submit sometime soon ;3

> So... you want to `std.process.fork` and then `exit(0)` straight afterwards in the parent process, and then continue waiting for full submission results in the child process, right? From the child process, we can still write to the same `stdout`, as long as we have the same fd (and we do). Not really, while I do want to wait for the submission results in the background, I also want the foreground process to keep the interactive terminal occupied until the verdict is ready. The intention is that only the foreground will write to `stdout`, so that if the user sends `^C` they can get back to work, and will (at least in the original intention) receive a desktop notification with a short summary, if they configure the second hook to do so. > Do you create a new session with `setsid()` to detach completely from terminal session, so that `wbij` child process is not killed, or do you do something else? How do you detect that terminal was closed? Yup, exactly! Right now the way I do this is: the parent and child processes have a pipe open, so that the child process can transfer the verdict to the parent and later display it. We can detect if the parent is dead if it closes the reading end of the pipe, which will make `std.posix.write` return `error.BrokenPipe`; if this happens the child process will just run the post-result hook and exit. There is an issue though, as `std.posix.errno` just does not compile in zig 0.15.2, from which it follows that `std.posix.setsid` is unusable; this means that the full functionality is blocked by #13. > I'm curious to see your results! : ) I'm just about to start committing parts of the code I've written over the past few days; for now it's all still WIP but expect a PR from [`kbity:feature/post-submit`](https://repos.adamm.rocks/kbity/wbij/src/branch/feature/post-submit) sometime soon ;3

Rows
Columns

Wait for submission result #4