feat(llmo): bounded PAPI active-version lookup in akamai getVersions - #3159
feat(llmo): bounded PAPI active-version lookup in akamai getVersions#3159adityamisra08 wants to merge 2 commits into
Conversation
getVersions derived the active staging/production versions by scanning
listActivations() — the property's full activation history on both networks —
whose payload and processing grow with the number of versions/activations, adding
latency to the Property step and exposing onboarding to PAPI/gateway timeouts on
large properties.
Replace that with three concurrent, bounded PAPI lookups: /versions/latest plus
/versions/latest?activatedOn={STAGING,PRODUCTION}. A network the property was
never activated on resolves to an absent entry rather than failing the request,
so the endpoint's cost is independent of activation history.
A bounded lookup returns a version record (no activation record), so activationId
is always null; the field is retained for response-shape stability.
LLMO-7225
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
This PR will trigger a minor release when merged. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Hey @adityamisra08,
⚠ Degraded review - no spec document was found for this change (searched the PR links, the touched repos' docs, the architecture/guidelines docs, and linked Jira). This review covers code-level quality but could not validate the change against an agreed design, so confidence is reduced. Add a spec link (PR template section 4) and re-request review for a full-confidence pass.
Verdict: Approve - clean, well-scoped refactor with no blocking issues.
Complexity: HIGH - medium diff, API surface change (OpenAPI schema modified).
Changes: Replaces unbounded PAPI activation-history scan in getVersions with three concurrent bounded version lookups, making endpoint cost independent of property history depth (3 files).
Note: Recommend a human read before merge - this change modifies a shared contract (OpenAPI spec docs/openapi/llmo-api.yaml). The bot review is a complement to, not a replacement for, a human read here.
Non-blocking (3): minor issues and suggestions
- nit:
activationIdtype change fromstringto[string, 'null'](alwaysnull) is a behavioral contract change for API consumers -docs/openapi/llmo-api.yaml:6971. Schema is correctly updated and PR description is transparent, but consumers reading this field for display or correlation will silently getnull. - nit: error test only rejects one of three
Promise.allsources (STAGING lookup) -test/controllers/llmo/llmo-akamai.test.js:999. Consider adding a case wheregetLatestVersionitself rejects, to cover all three rejection paths. - suggestion: guard on
staging?.propertyVersion != nullinstead ofif (staging)for defensiveness against unexpected return shapes from the unreleased client -src/controllers/llmo/llmo-akamai.js:1211.
Skill: pr-review | Model: us.anthropic.claude-opus-4-6-v1[1m] | Duration: 2m 59s | Cost: $5.39 | Commit: 63af0ef59805e75f4c3d9332478e2e04e5e0cb95
If this code review was useful, please react with 👍. Otherwise, react with 👎.
Summary
getVersionsderived the active staging/production versions by scanninglistActivations()— the property's full activation history on both networks. That is one PAPI call, but its payload and processing grow with the property's activation history, adding latency to the Property step and exposing onboarding to PAPI/gateway timeouts on properties with hundreds of versions.This replaces the history scan with three concurrent, bounded PAPI lookups whose cost is independent of activation history:
/versions/latest/versions/latest?activatedOn=STAGING/versions/latest?activatedOn=PRODUCTIONA network the property was never activated on resolves to an absent
activeentry rather than failing the request.What changed
src/controllers/llmo/llmo-akamai.js—getVersionsnow runs the three bounded lookups viaPromise.alland buildsactivefrom the per-network results. NolistActivations().activationIdis alwaysnull; the field is retained for response-shape stability.docs/openapi/llmo-api.yaml—akamai-active-activation:activationIdis nowtype: [string, 'null']with an always-null note;activedescription updated.test/controllers/llmo/llmo-akamai.test.js—getVersionssuite rewritten: per-network active version, assertslistActivationsis never called, never-activated network omitted, emptyactivemap, PAPI-failure → 502.Testing
npx mocha --timeout 10000 test/controllers/llmo/llmo-akamai.test.js— 115 passing.npm run lintclean;npm run docs:lintvalid.docs/index.htmlintentionally not regenerated —docs:buildproduces hash-noise off the canonical CI toolchain (see repo CLAUDE.md). Spec files are the source of truth; regen on CI.Dependency
Requires the release of
@adobe/spacecat-shared-akamai-clientfrom adobe/spacecat-shared#1901 (addsgetLatestVersionActivatedOn). Merge/release that first, then bump the dep here — CI will fail until the bump lands.Breaking changes
None. Same endpoint/shape;
active[network].activationIdis now alwaysnull(was populated from the activation record, unconsumed by the UI).🤖 Generated with Claude Code