Follow-up from the 1.10.1 audit PR (#784) review by @tacoverdo (item 2).
Context
On a branded host (PROGRESS_PLANNER_BRANDING_ID defined, e.g. pp-hosts) with no license key yet, Base::init() makes two blocking remote calls (get-nonce + onboard) to fetch the key. After #784 this only fires for an administrator, so anonymous/low-privileged visitors can't trigger it.
Remaining concern (Taco): if the SaaS is persistently down, every admin request — including admin-ajax and Heartbeat — still makes the two blocking calls until a key exists. That can slow every admin page on those sites and amplify traffic against the SaaS.
The trade-off (why not a flat 1-hour transient)
A naive "set a 1-hour skip transient on any failure" is wrong: if the admin's first request fails for a transient reason (network blip, cold start), the customer would be stranded un-onboarded for an hour. On pp-hosts this is the post-Extendify front-end homepage flow that is supposed to just work, so a transient failure must not block onboarding for an hour.
Proposed approach
A short, escalating back-off rather than a flat hour:
- Track consecutive failures (count + timestamp), reset on success.
- 1st failure: retry freely (or after ~30s).
- Escalate only on repeated consecutive failures (e.g. 1 min → 5 min → 1 hr cap).
This throttles a real outage without blocking the happy path on a one-off blip. A simple fixed ~60s back-off is an acceptable minimum (a transient failure costs ~1 min, not 1 hr).
Acceptance
- A single transient failure does not meaningfully delay onboarding on the next request.
- A persistent SaaS outage backs off to at most a bounded retry rate per admin.
- Verified against the branded pp-hosts flow (front-end homepage onboarding still works).
Where
classes/class-base.php — the auto-onboard block in init().classes/utils/class-onboard.php — make_remote_onboarding_request().
Note: the code lives in the PP plugin (pp-hosts vendors it and defines the branding constant), so the fix belongs here even though the symptom only appears on branded hosts.
Follow-up from the 1.10.1 audit PR (#784) review by @tacoverdo (item 2).
Context
On a branded host (
PROGRESS_PLANNER_BRANDING_IDdefined, e.g. pp-hosts) with no license key yet,Base::init()makes two blocking remote calls (get-nonce+onboard) to fetch the key. After #784 this only fires for an administrator, so anonymous/low-privileged visitors can't trigger it.Remaining concern (Taco): if the SaaS is persistently down, every admin request — including admin-ajax and Heartbeat — still makes the two blocking calls until a key exists. That can slow every admin page on those sites and amplify traffic against the SaaS.
The trade-off (why not a flat 1-hour transient)
A naive "set a 1-hour skip transient on any failure" is wrong: if the admin's first request fails for a transient reason (network blip, cold start), the customer would be stranded un-onboarded for an hour. On pp-hosts this is the post-Extendify front-end homepage flow that is supposed to just work, so a transient failure must not block onboarding for an hour.
Proposed approach
A short, escalating back-off rather than a flat hour:
This throttles a real outage without blocking the happy path on a one-off blip. A simple fixed ~60s back-off is an acceptable minimum (a transient failure costs ~1 min, not 1 hr).
Acceptance
Where
classes/class-base.php— the auto-onboard block ininit().classes/utils/class-onboard.php—make_remote_onboarding_request().Note: the code lives in the PP plugin (pp-hosts vendors it and defines the branding constant), so the fix belongs here even though the symptom only appears on branded hosts.