feat: Use separate superpositions for serving RC and dashboard#311
feat: Use separate superpositions for serving RC and dashboard#311yuvrajjsingh0 wants to merge 1 commit into
Conversation
Changed Files
|
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThe changes introduce authenticated Superposition support with separate RC (Release Candidate) endpoint configuration. New environment variables enable cookie-based auth and RC-specific URL/token overrides. Configuration, scripts, and application code are updated to create and use distinct Superposition clients for dashboard and RC operations. Changes
Sequence DiagramsequenceDiagram
participant App as Application<br/>(main.rs)
participant Config as Configuration<br/>(config.rs)
participant Auth as Auth Interceptor<br/>Closure
participant SDK as Superposition SDK<br/>Clients
participant Dashboard as Dashboard<br/>Endpoint
participant RC as RC<br/>Endpoint
App->>Config: Load environment config
Config-->>App: AppConfig with RC URLs & tokens
App->>Auth: Create client builder for Dashboard
Note over Auth: enable_authenticated_superposition?
Auth->>SDK: Inject auth cookie interceptor<br/>(user/org tokens)
SDK->>Dashboard: Client created with auth
Dashboard-->>SDK: Connection established
App->>Auth: Create client builder for RC
Auth->>SDK: Inject auth cookie interceptor<br/>(RC tokens or defaults)
SDK->>RC: RC Client created with auth
RC-->>SDK: Connection established
App->>App: Store both clients in AppState
Note over App: superposition_client<br/>rc_superposition_client
App->>App: Release handler receives rc_superposition_client
App->>SDK: Call applicable_variants() & get_resolved_config()
SDK->>RC: Authenticated requests with cookies
RC-->>SDK: Return config variants
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
airborne_server/.env.example (1)
3-10: LGTM — dotenv-linterUnorderedKeywarnings are safely ignorable.The Superposition variables are grouped semantically (URL, org id, auth toggle, tokens, RC tokens), which reads better than strict alphabetical ordering. The static-analysis warnings about key ordering don't reflect a real issue here.
One small thing:
SUPERPOSITION_RC_URLin an example file can just stay blank (same as the tokens), sinceairborne_server/src/config.rsfalls back toSUPERPOSITION_URL. Duplicatinghttp://localhost:8080isn't harmful but also documents the fallback less clearly.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@airborne_server/.env.example` around lines 3 - 10, Change the example env to leave SUPERPOSITION_RC_URL blank to show the real fallback: update the .env.example so SUPERPOSITION_RC_URL is empty (like the token vars) and add a brief comment if desired; this makes the implicit fallback to SUPERPOSITION_URL (as used in config reading logic) clearer while keeping the semantic grouping of the Superposition keys intact.airborne_server/README.md (1)
299-304: Docs align with the implementation.Descriptions for
SUPERPOSITION_RC_URL,ENABLE_AUTHENTICATED_SUPERPOSITION, and the user/org/RC token env vars match the fallback logic inairborne_server/src/config.rsand the cookie format (user=...; org_<SUPERPOSITION_ORG_ID>=...) built inairborne_server/src/main.rs.Optional nit:
SUPERPOSITION_TOKEN(used as thebearer_tokeninSrsConfig::builder()inmain.rs) is added to.env.exampleand to the encrypted-secrets list in both scripts, but is not called out in this section. Consider adding a short line documenting it for completeness.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@airborne_server/README.md` around lines 299 - 304, README.md is missing documentation for SUPERPOSITION_TOKEN which is used as the bearer_token passed to SrsConfig::builder() in main.rs; update the README env vars list to add a short line describing SUPERPOSITION_TOKEN (its purpose as the bearer token for Superposition SDK requests, default/usage) and mention it is included in .env.example and encrypted-secrets scripts so docs match implementation.airborne_server/src/main.rs (1)
206-264: Solid DRY refactor; fallback + panic semantics are correct.The closure cleanly factors out the unauthenticated vs. cookie-intercepted construction, and the env-hint strings (
"SUPERPOSITION_RC_USER_TOKEN or SUPERPOSITION_USER_TOKEN") correctly document the fallback chain fromairborne_server/src/config.rs(get_optional_secret(...).or_else(|| superposition_user_token.clone())). Because of that chain, the panic only fires when both the RC-specific and base tokens are unset whileENABLE_AUTHENTICATED_SUPERPOSITION=true, which is the intended fail-fast behavior.Minor optional polish: the two inner
Client::from_conf(...)calls are almost identical except for.interceptor(...). You can collapse them further if you like:♻️ Optional simplification
- if app_config.enable_authenticated_superposition { - let superposition_user_token = user_token.unwrap_or_else(|| { - panic!( - "{} must be set when ENABLE_AUTHENTICATED_SUPERPOSITION=true", - user_token_env_hint - ) - }); - let superposition_org_token = org_token.unwrap_or_else(|| { - panic!( - "{} must be set when ENABLE_AUTHENTICATED_SUPERPOSITION=true", - org_token_env_hint - ) - }); - - // Inject Auth cookie for Superposition SDK calls - let cookie_interceptor = CookieIntercept::new(format!( - "user={}; org_{}={}", - superposition_user_token, superposition_org_id_env, superposition_org_token, - )); - - superposition_sdk::Client::from_conf( - SrsConfig::builder() - .endpoint_url(endpoint_url) - .behavior_version_latest() - .bearer_token(superposition_token.clone().into()) - .interceptor(cookie_interceptor) - .build(), - ) - } else { - superposition_sdk::Client::from_conf( - SrsConfig::builder() - .endpoint_url(endpoint_url) - .behavior_version_latest() - .bearer_token(superposition_token.clone().into()) - .build(), - ) - } + let mut builder = SrsConfig::builder() + .endpoint_url(endpoint_url) + .behavior_version_latest() + .bearer_token(superposition_token.clone().into()); + + if app_config.enable_authenticated_superposition { + let user = user_token.unwrap_or_else(|| { + panic!("{} must be set when ENABLE_AUTHENTICATED_SUPERPOSITION=true", user_token_env_hint) + }); + let org = org_token.unwrap_or_else(|| { + panic!("{} must be set when ENABLE_AUTHENTICATED_SUPERPOSITION=true", org_token_env_hint) + }); + builder = builder.interceptor(CookieIntercept::new(format!( + "user={}; org_{}={}", + user, superposition_org_id_env, org, + ))); + } + + superposition_sdk::Client::from_conf(builder.build())🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@airborne_server/src/main.rs` around lines 206 - 264, The two near-identical superposition client constructions in the create_superposition_client closure can be collapsed: build the SrsConfig with SrsConfig::builder().endpoint_url(endpoint_url).behavior_version_latest().bearer_token(superposition_token.clone().into()), then if app_config.enable_authenticated_superposition create the CookieIntercept and call .interceptor(cookie_interceptor) on that builder before .build(); finally call superposition_sdk::Client::from_conf(...) once with the finalized config. Target symbols: create_superposition_client, SrsConfig::builder, .interceptor, CookieIntercept, superposition_sdk::Client::from_conf.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@airborne_server/scripts/encrypt-envs.sh`:
- Around line 69-129: read_env_raw currently returns the RHS verbatim (including
surrounding shell quotes), causing nested-quoting when
sync_superposition_rc_env_defaults copies values; update read_env_raw to strip
surrounding shell quotes (i.e., call the existing strip_shell_quotes helper used
by init-localstack.sh or implement equivalent logic) before returning the value,
and ensure strip_shell_quotes is defined or sourced so upsert_env_raw writes the
normalized unquoted value; reference read_env_raw, upsert_env_raw,
strip_shell_quotes, and sync_superposition_rc_env_defaults when making the
change.
In `@airborne_server/scripts/init-localstack.sh`:
- Around line 160-184: sync_superposition_rc_env_defaults copies encrypted token
blobs from SUPERPOSITION_USER_TOKEN / SUPERPOSITION_ORG_TOKEN into their RC
counterparts; change it to detect encrypted-looking values and skip copying so
the main get_value() logic can handle decryption/reset. In
sync_superposition_rc_env_defaults, after reading superposition_user_token and
superposition_org_token via read_env_value, check whether each value appears to
be an encrypted JSON blob (e.g., a string that parses to JSON and contains keys
like "nonce" and "ciphertext" or matches a regex indicating JSON with those
keys) and only call upsert_env_var for the RC variables when the source token is
not encrypted; keep existing behavior for plain-text values. Ensure you use the
same helper functions (read_env_value, upsert_env_var) and leave get_value()
unchanged.
---
Nitpick comments:
In `@airborne_server/.env.example`:
- Around line 3-10: Change the example env to leave SUPERPOSITION_RC_URL blank
to show the real fallback: update the .env.example so SUPERPOSITION_RC_URL is
empty (like the token vars) and add a brief comment if desired; this makes the
implicit fallback to SUPERPOSITION_URL (as used in config reading logic) clearer
while keeping the semantic grouping of the Superposition keys intact.
In `@airborne_server/README.md`:
- Around line 299-304: README.md is missing documentation for
SUPERPOSITION_TOKEN which is used as the bearer_token passed to
SrsConfig::builder() in main.rs; update the README env vars list to add a short
line describing SUPERPOSITION_TOKEN (its purpose as the bearer token for
Superposition SDK requests, default/usage) and mention it is included in
.env.example and encrypted-secrets scripts so docs match implementation.
In `@airborne_server/src/main.rs`:
- Around line 206-264: The two near-identical superposition client constructions
in the create_superposition_client closure can be collapsed: build the SrsConfig
with
SrsConfig::builder().endpoint_url(endpoint_url).behavior_version_latest().bearer_token(superposition_token.clone().into()),
then if app_config.enable_authenticated_superposition create the CookieIntercept
and call .interceptor(cookie_interceptor) on that builder before .build();
finally call superposition_sdk::Client::from_conf(...) once with the finalized
config. Target symbols: create_superposition_client, SrsConfig::builder,
.interceptor, CookieIntercept, superposition_sdk::Client::from_conf.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c5cdf2d3-d908-4ccb-a1c9-fa4f27a0dc26
📒 Files selected for processing (8)
airborne_server/.env.exampleairborne_server/README.mdairborne_server/scripts/encrypt-envs.shairborne_server/scripts/init-localstack.shairborne_server/src/config.rsairborne_server/src/main.rsairborne_server/src/release.rsairborne_server/src/types.rs
29da525 to
ab606aa
Compare
Summary by CodeRabbit
New Features
Documentation