Events.problem ​

Contract 2.0.0 · package sha256 a857eca95b35921109faf997094bb4192f12527d9d0fcd4be7e97f06425bad6e · generated from configurator-runtime.d.ts by services/onsite-scripter/scripts/build-contract-docs.mjs; edit the source, not this file.

Property of Events · stable · since 2.0.0

ts
'problem': {
  readonly problem: Problem;
};

A Problem was recorded (also in info().problems). A 'handler-threw', 'handler-async' or 'handler-rejected' that a 'problem' handler caused, and any Problem of an operation it called, is recorded but fires no 'problem' event. It fires at once, when recorded, not after a frame; one recorded while handlers run (a commit's round or another 'problem') fires after them, never nested; one recorded while work or a beforeCommit function is synchronously on the stack fires when that part returns (spec section 6.11). One recorded while boot was pending fired before any handler existed: read it from info().problems after boot (spec section 5.1).

Fields ​

problem ​

ts
readonly problem: Problem;

Generic-API test (spec 3.1) ​

Rule Result
1. Neutral name pass: problem names no product
2. A precedent pass: HTMLCanvasElement webglcontextlost (row G51)
3. Two apps, or labs pass: 21 apps (ledger: app-4762caacdc, app-e3b47169bc, app-f9a32142f1; fleet cross-check: app-04c2774145, app-0c773a4ee3, app-37356bf09f, app-378d190f1b, app-4762caacdc, app-4fd23bc869, app-822bb9d6aa, app-8675b3225c and 13 more)
4. The cheaper fix first decided per need in Appendix B: rows G51 at tier stable (a member only where no rule, data, asset or app code serves the need)