Replies: 2 comments 3 replies
-
Any help would be appreciated here....? |
Beta Was this translation helpful? Give feedback.
0 replies
-
You do have to track this yourself on the callback context. You're right that it would be easier if we tracked this automatically. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi folks,
Looking at the contract as written, how do I guarantee the following lines?(see quoted below). From what I can tell, no plugin(this one included) contains the original start time of the resource call. Is it my handler's problem to track original call time in the callback context? Shouldnt this be included on the generated classes or within the framework Models? I can then just interrogate and respond with error, or even better let framework respond with error... Right now as written in contract - we dont know when to return since we do not have the start time and the resource schema of timeoutinMinutes is not exposed to us via any generated classes, correct? I see it is used to set maximum time on assuming the role only. That doesnt allow us to honor contract for less than 60 minutes for a single request: see here
Timeout Implementation:
- Do we have to guarantee any kind of runtime for functions? IE if this is running in Lambda is it our responsibility to kill function before hitting 15 minutes? Shouldn't it be the framework's job to give us total allowable execution time? Nothing in contract docs state allowable execution time. Ideally you would include a line like :A list/create/update/delete/read request MUST return within NN seconds of continuous execution. If you need more time, add data to callback context and handle in next call
^ is handled by
MUST always return a ProgressEvent object within 60 seconds
Contract Lines
Beta Was this translation helpful? Give feedback.
All reactions