timeout_after parameter not working as expected

[seif-fmfx]

Describe the bug
timeout_after parameter not working as expected

To Reproduce
Steps to reproduce the behavior:
set the timeout_after parameter

Expected behavior
value is respected

Desktop (please complete the following information):

• OS: windows
• Browser edge
• Version irrelecant

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Attemptede a fix here #107

[seif-fmfx]

For anyone else that comes here, we changed the parameter we are setting to timeout instead of timeout_after which gives you a warning from gha but it works (i.e. the timeout is respected) .

[mfalconi-perle]

Is this what is causing new seen issues, wherein a failure is received before the task can actually complete on the octopus deploy service?

[seif-fmfx]

@mfalconi-perle sounds like it. for us it manifested as:

waiting for task ServerTasks-98292. Status: Executing. Error: 🐙 Could not determine Octopus Deploy task state

but the deployment in octopus was still running

[mfalconi-perle]

@mfalconi-perle sounds like it. for us it manifested as:

waiting for task ServerTasks-98292. Status: Executing. Error: 🐙 Could not determine Octopus Deploy task state

but the deployment in octopus was still running

Yeah this is exactly what I am getting on my actions as well. Thanks, glad to know this was reported. We have been confused seeing our changes and seeing the deployments running but always getting failures on the actions report

[cmyllis]

@hnrkndrssn Fix done here seems wrong: #22
Can you re-open it?

[seif-fmfx]

@hnrkndrssn @cmyllis that fix is correct, but highlighted another problem which this issue is about and that is that task is reading the input from a parameter called timeout when it should be reading timeout_after

[bnelsonjha]

@seif-fmfx Thanks for doing on this! Timeout is working for me. I am using the latest version. Either the code should be fixed or the front page documentation should be fixed.

[mfalconi-perle]

Was there a new release in regards to this issue? Seeing a new Actions warning pop up as of today

Unexpected input(s) 'timeout', valid inputs are ['server_task_id', 'polling_interval', 'timeout_after', 'hide_progress', 'server', 'api_key', 'space']

Whereas before timeout was working where timeout_after was not has this been fixed then?

[seif-fmfx]

@mfalconi-perle you get that warning because the action says the the field is called timeout_after but you are sending timeout which doesnt match what the action is configured to read. Nothing has changed so you need to use timeout to control it and ignore that warning.

[jonagh]

This seems like a pretty simple fix, Octopus. See...

await-task-action/src/input-parameters.ts

Line 46 in e1920eb

const timeoutInput = getInput('timeout')

Should be reading in timeout_after instead of timeout:

  const timeoutInput = getInput('timeout_after') || getInput('timeout') // The "timeout_after" naming is correct, fallback to "timeout" supports old/incorrect naming.