Skip to content

feat(llmo): bounded PAPI active-version lookup in akamai getVersions - #3159

Open
adityamisra08 wants to merge 2 commits into
mainfrom
feat/LLMO-7225-akamai-automation-improvements
Open

feat(llmo): bounded PAPI active-version lookup in akamai getVersions#3159
adityamisra08 wants to merge 2 commits into
mainfrom
feat/LLMO-7225-akamai-automation-improvements

Conversation

@adityamisra08

Copy link
Copy Markdown
Contributor

Summary

getVersions derived the active staging/production versions by scanning listActivations() — 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=PRODUCTION

A network the property was never activated on resolves to an absent active entry rather than failing the request.

What changed

  • src/controllers/llmo/llmo-akamai.jsgetVersions now runs the three bounded lookups via Promise.all and builds active from the per-network results. No listActivations().
    • A bounded lookup returns a version record (no activation record), so activationId is always null; the field is retained for response-shape stability.
  • docs/openapi/llmo-api.yamlakamai-active-activation: activationId is now type: [string, 'null'] with an always-null note; active description updated.
  • test/controllers/llmo/llmo-akamai.test.jsgetVersions suite rewritten: per-network active version, asserts listActivations is never called, never-activated network omitted, empty active map, PAPI-failure → 502.

Testing

  • npx mocha --timeout 10000 test/controllers/llmo/llmo-akamai.test.js115 passing.
  • npm run lint clean; npm run docs:lint valid.
  • docs/index.html intentionally not regenerated — docs:build produces 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-client from adobe/spacecat-shared#1901 (adds getLatestVersionActivatedOn). Merge/release that first, then bump the dep here — CI will fail until the bump lands.

Breaking changes

None. Same endpoint/shape; active[network].activationId is now always null (was populated from the activation record, unconsumed by the UI).

🤖 Generated with Claude Code

adityamisra08 and others added 2 commits August 31, 2026 16:22
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>
@github-actions

Copy link
Copy Markdown

This PR will trigger a minor release when merged.

@adityamisra08 adityamisra08 self-assigned this Aug 31, 2026
@codecov

codecov Bot commented Aug 31, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@MysticatBot MysticatBot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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: activationId type change from string to [string, 'null'] (always null) 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 get null.
  • nit: error test only rejects one of three Promise.all sources (STAGING lookup) - test/controllers/llmo/llmo-akamai.test.js:999. Consider adding a case where getLatestVersion itself rejects, to cover all three rejection paths.
  • suggestion: guard on staging?.propertyVersion != null instead of if (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 👎.

@MysticatBot MysticatBot added ai-reviewed Reviewed by AI complexity:high AI-assessed PR complexity: HIGH needs-human-review AI reviewer recommends a human read before merge labels Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai-reviewed Reviewed by AI complexity:high AI-assessed PR complexity: HIGH needs-human-review AI reviewer recommends a human read before merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants