Build1 publisher2 min readPublished Updated
Atlassian ships @forge/bridge with view.submit() typed to accept any object
Atlassian's Forge portal property panel needs a payload carrying fields and isValid, but @forge/bridge types the argument as an optional any and the return as void, so a wrong guess compiles and resolves without writing anything.
The Engineer · Build desk
What happened
- A developer on the Atlassian developer forum built a Forge portal request-create property panel, called view.submit(), and got neither a thrown error nor a console warning.
- The @forge/bridge package's own shipped types declare submit as (payload?: any) => Promise<void>, a signature current as of version 7.0.0, so any object compiles and any object resolves.
- Atlassian's manifest reference for the module documents the required payload in a Form data schema table: a fields list of key/value objects plus a required isValid boolean.
- Three months after the first post, a second developer posting as Vikram1 asked on the same thread how the first had managed to submit a value to a property.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Anyone writing one of these handlers has to open Atlassian's manifest reference first, because the installed type definition will not tell them what the payload needs to contain.
- cost The developer pays in debugging time instead of in build errors: the first signal of a bad payload is a missing property or a 404 on a later backend read.
- constraint Verification requires running the portal flow on a real or sandbox Jira Cloud site, since neither the compiler nor the resolved promise can distinguish a good payload from a bad one.
Read the shipped declaration as a contract and it commits to very little. The question mark in `(payload?: any)` makes the argument optional, so a bare `view.submit()` type-checks, and `any` will take a number as readily as the object you guessed at [15]. The declared return is `Promise<void>`, so awaiting the call gives back nothing to test [16].
Atlassian's manifest reference makes `isValid` required, and the page's own worked example passes it explicitly: `await view.submit({ fields: [property], isValid: true })` [5]. Had the shipped type described that schema instead of `any`, a call missing `isValid` would be a compile error [17].
Runtime does not catch it either. No error is thrown at submit time, and the call resolves normally whether the shape was right or wrong [8]. The first developer on the forum wrote, "As you see, property is undefined." [6] He then tried reading the value from the backend with `api.asApp().requestJira()` and got a 404, because the property had never been written [7]. The tutorial groups this with another silent `@forge/bridge` failure mode, a call that resolves cleanly while doing something other than what you asked [19].
Correct calls are not much louder. The write does not happen at the moment `view.submit()` resolves, according to the tutorial [11], and the stored value is read back from a different module, `jiraServiceManagement:portalRequestDetail` [12].
The fix, when the original poster finally posted it, was one wrong object shape [10]. Three months sit between the two forum posts [18]. That gap measures how long the question went unanswered on the thread; neither post says how much time either developer spent on the problem [18].
The tutorial's author is explicit about the limits of his evidence: the forum account is his only first-hand record of the silent failure, and he did not run a fresh wrong-shape submit against a live app to show it [13]. The signature, by contrast, is checkable by anyone in their own installed copy, and it is current as of `@forge/bridge` 7.0.0 [3]. He also flags the one adjacent problem he could not close out, turning the stored issue property into a real Jira custom field. Nobody in the source threads has finished that [14].
What to watch
- Whether Atlassian narrows submit's payload type past @forge/bridge 7.0.0; apps passing a wrong shape today would then fail at build instead of at runtime.
- Whether anyone publishes a working path from the stored issue property to a real Jira custom field, the problem the source threads left open.
- A reproduction of a wrong-shape submit against a live app, which would put first-hand evidence behind the silent-failure account.