docs: the timer-expiration exception during test runs
The BIP events flow during a run (v3.25.3), but a TIMER MANAGEMENT timer the card armed still does not fire then - the v3.25.1 guard retries it every 5 s until the run ends. Documented as a deliberate exception to the "the card's own conversation continues" rule, in the authoring guide and both AGENTS, to review later. 883 frontend + 873 Python (unchanged).
This commit is contained in:
@@ -534,7 +534,11 @@ the data really flows to/from the configured BIP target, and the BIP events
|
|||||||
(Data available, Channel status) flow for the channels the card itself opened -
|
(Data available, Channel status) flow for the channels the card itself opened -
|
||||||
so an applet's own HTTP/BIP conversation completes inside a scripted run. The
|
so an applet's own HTTP/BIP conversation completes inside a scripted run. The
|
||||||
BIP **control** API stays blocked while a run is active (409), like the
|
BIP **control** API stays blocked while a run is active (409), like the
|
||||||
terminal's other automatic actions (polling, timers, menu).
|
terminal's other automatic actions (polling, menu). The one remaining
|
||||||
|
automatic action that still waits is the **timer expiration** event: a
|
||||||
|
TIMER MANAGEMENT timer the card armed is not fired during a run (it retries
|
||||||
|
every 5 s and fires when the run ends) - a deliberate exception to the
|
||||||
|
"the card's own conversation continues" rule, to review later (v3.25.3).
|
||||||
|
|
||||||
A step's `respond` overrides the terminal when it carries `raw` TLVs or a
|
A step's `respond` overrides the terminal when it carries `raw` TLVs or a
|
||||||
**non-ok result** - the way to script an applet error path:
|
**non-ok result** - the way to script an applet error path:
|
||||||
|
|||||||
Reference in New Issue
Block a user