ATF step timeout type-checks in Fluent but is never emitted to sys_atf_step (SDK 4.11.0)

[sonisoft-cnanda]

Summary

timeout is accepted on an ATF step in Fluent — it is part of StandardStepValues and type-checks
against a Duration — but it is never emitted into the sys_atf_step record. The built XML
contains <timeout/>, the installed step reads 0 Seconds, and there is no error or warning at
build, install or run time.

SDK 4.11.0, @servicenow/sdk + now-sdk build / now-sdk install.

Why this one is worth fixing rather than documenting

Timeout is how an ATF step waits. On a stock instance the field is populated on Server-category
steps in real use, not just client ones — counted on one instance:

Step	Steps carrying a non-zero Timeout	Category
Record Query (Deprecated)	85	Server
Record Query	77	Server
Record Validation	60	Server
Assert Text on Page (Custom UI)	60	Custom UI
Field Values Validation	54	Form
Impersonate	5	Server
Create a User	4	Server
Run Server Side Script	2	Server

A step authored in Fluent to wait therefore does not wait, and the failure is invisible in the
direction that costs most: the test still builds, still installs, and still passes on a fast
instance. It only misbehaves against a slower instance or a genuinely asynchronous condition, where
it reports a false negative instead of waiting — with nothing at author time indicating the value
went nowhere.

Reproduce

import { Test } from '@servicenow/sdk/core'

export const probe = Test(
    { $id: Now.ID['probe'], name: 'Timeout probe', active: true },
    (atf) => {
        atf.server.recordQuery({
            $id: Now.ID['probe-query'],
            table: 'sysapproval_approver',
            fieldValues: 'state=requested',
            assert: 'records_match_query',
            timeout: Duration({ seconds: 30 }),
        })
    }
)

npx now-sdk build
grep -o '<timeout>[^<]*</timeout>\|<timeout/>' dist/app/update/sys_atf_step_*.xml

Expected: <timeout>1970-01-01 00:00:30</timeout>
Actual: <timeout/> — and after now-sdk install the step's Timeout shows 0 Seconds.

Evidence it is the emit, not the input

• The compiler knows the property. Passing a string instead of a Duration fails with
  TS2559: Type 'string' has no properties in common with type 'Duration'. So timeout is on the
  typed surface; only the emit drops it.
• Duration serialises correctly elsewhere in the same build.
  wfa.flowLogic.waitForADuration({ durationType: 'explicit_duration', duration: Duration({ seconds: 30 }) })
  emits timer_duration = 1970-01-01 00:00:30 in the same project and the same build. This looks
  specific to the ATF step mapping rather than to Duration handling generally.
• The platform accepts the value fine when it is written directly (see workaround), so the
  instance side is not at fault.
• $override is not available as an escape hatch here. Adding
  $override: { timeout: '1970-01-01 00:00:45' } to the step config fails with
  TS2353: '$override' does not exist in type ... & StandardStepValues. $override is exposed on
  top-level API constructors, not on the step config objects inside a Test(...) body — so there
  is currently no way to set this from Fluent at all.

Workaround

Patch the step after install. Fluent already pins each step's sys_id in keys.ts, so this is
deterministic and repeatable:

// keys.ts:  'atf-my-step': { table: 'sys_atf_step', id: '744e3f97...' }
var st = new GlideRecord('sys_atf_step');
st.get('744e3f977c604c42bdd7e84535431748');
st.timeout = new GlideDuration(30 * 1000);   // milliseconds
st.update();

Two notes that cost time working this out:

• It must be a GlideDuration in milliseconds. st.setValue('timeout', 30) stores
  1970-01-01 00:00:00, silently.
• Re-running now-sdk install does not appear to reset the value, but any workaround that lives
  outside the app is one more thing to remember at promotion time — which is the argument for
  fixing the emit.

Suggested resolution

Emit timeout onto sys_atf_step for every step category that has the field (which is all of
them — it is defined on sys_atf_step itself, not per step config).

If the intent is that timeout should not be settable for some step types, then rejecting it at
build time would be an equally good outcome. The problem is not that it is unsupported; it is
that it is accepted, type-checked, and then silently discarded.

Environment

• SDK 4.11.0
• Instance: Zurich-era, ATF with 119 step configs
• Reproduced on atf.server.recordQuery; the field is on sys_atf_step so it should affect every
  step type equally.

[sonisoft-cnanda]

@bryce-godfrey FYI