branch create reports success on signals that do not mean the branch is usable. Three related defects, all measured against real branches on ap-southeast (all deleted afterwards). The cloud-side root cause is tracked in InsForge/InsForge#1790; this issue is the part that lives in the CLI.
1. ready is a control-plane state, not readiness
pollUntilReady returns the moment branch_state === 'ready' and never contacts the branch's own host. branch_state flips when the provisioning job returns, while the instance is still coming up — every request to https://<appkey>.<region>.insforge.app resets until it does.
Measured: the host started serving at t+2m in one case and t+11.5m in another, with branch_state reading ready the whole time.
Because create auto-switches the directory onto that host, the failure surfaces on the next command:
$ insforge db query "select 1"
{"error":"fetch failed","code":"UNKNOWN_ERROR"}
2. POLL_TIMEOUT_MS (5 min) is below the observed provisioning time
The 11.5-minute branch was reported as "still in 'creating' state" when it was simply not finished yet.
3. A failed create can leave a live branch behind
createBranchApi carries no idempotency key. A transport failure on the response leg — the POST arrived, the branch was created — throws before created is bound, so the CLI exits non-zero with no id and no name while a branch exists and bills:
$ insforge branch create <name> --mode schema-only --no-switch
{"error":"Connection to api.insforge.dev was reset. A proxy, VPN, or firewall may be interfering."}
# exit 1
$ insforge branch list
# the branch is there, branch_state "creating"
It then refused delete for about five minutes with "Branch is currently busy (creating or merging)." before the state flipped and the delete succeeded.
Minor, but it cost real triage time
ossFetch calls fetch unguarded, unlike platformFetch, so a dead data plane surfaces as the generic UNKNOWN_ERROR instead of naming the host.
Environment
@insforge/cli 0.1.99 / main at 64c0859, Node 26, Windows- Managed cloud,
ap-southeast, service version 2.2.6 (re-checked on 2.2.7 — the backend diff there is the keepAliveTimeout fix, which is a different class and changes nothing here)
- Observed across eight branches (
--mode schema-only ×7, --mode full ×1); identical in both modes
Proposed fix
Wait for the branch's own /api/health before reporting success, raise the poll ceiling past the observed provisioning time, adopt a branch that exists after a transport failure (never after an API rejection, and never one that predates the request), and route ossFetch errors through formatFetchError.
I have this implemented and tested — I'd like this assigned to me, and I'll link the PR to it. Apologies for opening the PR first; I hadn't read the contribution workflow before submitting.
branch createreports success on signals that do not mean the branch is usable. Three related defects, all measured against real branches onap-southeast(all deleted afterwards). The cloud-side root cause is tracked in InsForge/InsForge#1790; this issue is the part that lives in the CLI.1.
readyis a control-plane state, not readinesspollUntilReadyreturns the momentbranch_state === 'ready'and never contacts the branch's own host.branch_stateflips when the provisioning job returns, while the instance is still coming up — every request tohttps://<appkey>.<region>.insforge.appresets until it does.Measured: the host started serving at t+2m in one case and t+11.5m in another, with
branch_statereadingreadythe whole time.Because
createauto-switches the directory onto that host, the failure surfaces on the next command:2.
POLL_TIMEOUT_MS(5 min) is below the observed provisioning timeThe 11.5-minute branch was reported as "still in 'creating' state" when it was simply not finished yet.
3. A failed
createcan leave a live branch behindcreateBranchApicarries no idempotency key. A transport failure on the response leg — the POST arrived, the branch was created — throws beforecreatedis bound, so the CLI exits non-zero with no id and no name while a branch exists and bills:It then refused
deletefor about five minutes with"Branch is currently busy (creating or merging)."before the state flipped and the delete succeeded.Minor, but it cost real triage time
ossFetchcallsfetchunguarded, unlikeplatformFetch, so a dead data plane surfaces as the genericUNKNOWN_ERRORinstead of naming the host.Environment
@insforge/cli0.1.99 /mainat64c0859, Node 26, Windowsap-southeast, service version 2.2.6 (re-checked on 2.2.7 — the backend diff there is thekeepAliveTimeoutfix, which is a different class and changes nothing here)--mode schema-only×7,--mode full×1); identical in both modesProposed fix
Wait for the branch's own
/api/healthbefore reporting success, raise the poll ceiling past the observed provisioning time, adopt a branch that exists after a transport failure (never after an API rejection, and never one that predates the request), and routeossFetcherrors throughformatFetchError.I have this implemented and tested — I'd like this assigned to me, and I'll link the PR to it. Apologies for opening the PR first; I hadn't read the contribution workflow before submitting.