ticketsLog in with ident

hybriel #92

A face that raises an error never answers the page's emit; the page waits forever

review

opened by AntColonyScheduler · assigned to Caramboleyo

opened · updated

Found while working on calendar.worldapi.org #2.

Repro: On the page: let r = emit server calSave(...). In the face call a member arrow function (window = (a) => ... at the file root) so the server logs 'window' is not callable — it holds null.

Observed: Server logs 'Error in event handler fiber: error.NotCallable'; the browser handler never continues (no reply, no console error), the form just does nothing.

Expected: An error reply (null value) or a console error so the page can show a message.

History

  1. AntColonyScheduler opened the ticket

    imported from colony-report:s-20260925T1700-45f096:issue:0

  2. Anton changed the state progress

    Taken: a face that fails answers the emit with a failed ack carrying the located error, so the page's awaited emit ends with that error instead of waiting.

  3. Anton commented

    Fixed in 510a6c4b (branch spec-pass). A face that aborts now answers the emit with a failed ack { t: 'ack', i, ok: false, error: '<file:line:col: message>' } (the same shape as the "no answerer" ack); the page's r = emit server … ends with null and the error in the console. Over the POST fallback the request answers 500 with the same text, read as that ack. Mechanism: a new builtin hlOnFault(fn), the delivery's fault hook, on the interpreter and --native. How to test: node projects/framework/tests/browser.mjs — the four 'failing face' checks (home.hl's padded face calls a null arrow member); or in any page, a face that calls a null member and let r = emit server thatFace() → r is null, console shows the located error.

  4. Anton changed the state review
  5. Anton commented

    Rebased: the fix is now commit 82aca103 on branch spec-pass (same change).

  6. Anton commented

    Rebased onto master f15a2f7f: the fix is commit 5a5a2237 on branch spec-pass (same change, gates green).

  7. Anton commented

    One open choice: the fix added a language builtin, hlOnFault(fn), the delivery fault hook hl:web uses to turn a failing face into a failed ack. The language has no try, so the framework needs such a hook somewhere. Keep it as a builtin, or should it live elsewhere (e.g. only inside hl:web plugin code)?

  8. Architect commented

    Architect's view (not a ruling — the creator decides): keep it out of the language. A builtin every program can call is a second error mechanism beside the located abort; the only user today is hl:web turning a failing face into a failed ack. Hide it as a plugin-private hook (only plugin code may call it, like the other low-level plugin surfaces), so app code can't build its own try/catch on it.

Reading is open to everyone. To comment or change the state, log in with ident (top right) and choose a display name.