GoCardless requisition creation time out

[hpernu]

Now there is no limit on how long ynabber waits for the requisition to be created. A script that starts ynabber would thus wait indefinitely even when the user is not around.

In some situations a long or even indefinite timeout may be desirable. On others, the requisition file is and will be updated separately or it is not desirable to consume resources to wait indefinitely. Depending on use case it may be more desirable to fail with an error and get an indication that something is wrong. This is especially useful when there is no controlling terminal and/or anybody actively viewing it.

In order not to confusingly change current behavior, let's keep the default timeout as infinity.

[martinohansen]

Have you tried the requisition hook? You could call out to a script that waits N time, restarts the Ynabber process or whatever you need.

[hpernu]

No but like I mentioned when making that feature, script style hooks are hard to use properly if using ynabber via docker. You'd need to have the hook scripts inside the container. Also, with current implementation, you cannot make the parent process(ynabber) to exit with a failure when using the hook. Even if the hook returns failure, the normal requisition process still continues. You would have to kill the parent process with the script. That might work but sounds a bit clumsy.

In my specific use case I might actually be able to pull this off with a hook though since I am not using the docker version in the scheduled batches although I am using docker when testing and updating requisition on my workstation. I'll have to consider that option.

Regardless:

• wouldn't it be better to fail ynabber if the requisition hook returns failure instead of continuing as if nothing had happened?
• a timeout waiting for requisition cannot be implemented via hook. Hook is run before requisition URL is printed and there is no hook on the wait loop

[martinohansen]

No but like I mentioned when making that feature, script style hooks are hard to use properly if using ynabber via docker. You'd need to have the hook scripts inside the container.

Its not that hard, you just use a volume mount.

Also, with current implementation, you cannot make the parent process(ynabber) to exit with a failure when using the hook. Even if the hook returns failure, the normal requisition process still continues. You would have to kill the parent process with the script. That might work but sounds a bit clumsy.

Thats a good idea! If the hook exits with an exit code thats not 0, we should return an error in the code. And if its not handled anywhere it should exit the program.

• wouldn't it be better to fail ynabber if the requisition hook returns failure instead of continuing as if nothing had happened?

+1

• a timeout waiting for requisition cannot be implemented via hook. Hook is run before requisition URL is printed and there is no hook on the wait loop

Does the link expire? If so, lets crash or recreate the requisition once that happens.

[hpernu]

No but like I mentioned when making that feature, script style hooks are hard to use properly if using ynabber via docker. You'd need to have the hook scripts inside the container.

Its not that hard, you just use a volume mount.

Yes, or rather create a new image based on ynabber, because you really can't do what you describe in Kubernetes or a general cloud service. There are also the availability and path of whatever shell the script uses and several other consideration which really make the hook option less useful in that context. And it is not a feasible replacement for timeout (see below).

Also, with current implementation, you cannot make the parent process(ynabber) to exit with a failure when using the hook. Even if the hook returns failure, the normal requisition process still continues. You would have to kill the parent process with the script. That might work but sounds a bit clumsy.

Thats a good idea! If the hook exits with an exit code thats not 0, we should return an error in the code. And if its not handled anywhere it should exit the program.

Yes, well, this has then to be done as part of the general error propagtion to top level.

• a timeout waiting for requisition cannot be implemented via hook. Hook is run before requisition URL is printed and there is no hook on the wait loop
  Does the link expire? If so, lets crash or recreate the requisition once that happens.

I don't know - possibly. But that's not the point. You can't handle the timeout via requisition hook because the hook runs before the requisition URL is printed. So there would still need to be a timer in ynabber code or you can wrap the whole thing in external timer such as timeout command on shell.

But if the implementation of this timer is not desirable in ynabber, I'll let it be. Even for ynabber, there are other issues which need fixing before I can use the latest one, as the effective operation has changed from previous versions.

This timeout issue has always been there and is a minor issue with expiring requisition in my CI pipelines which I actually use for automation rather than real CI. And as I realized, I could always wrap these inside a call to timeout. Using a hook is more complicated and will require change to the error handling. I'll get back to that anyway.