Skip to content

feat: can accept base64 payload while proxying to provider#2201

Merged
stalniy merged 3 commits intoakash-network:mainfrom
jzsfkzm:feature/2178-base64-payloads
Nov 12, 2025
Merged

feat: can accept base64 payload while proxying to provider#2201
stalniy merged 3 commits intoakash-network:mainfrom
jzsfkzm:feature/2178-base64-payloads

Conversation

@jzsfkzm
Copy link
Contributor

@jzsfkzm jzsfkzm commented Nov 11, 2025

refs #2178

A follow-up change in a week or so should remove the new field and old version of decoding.

Summary by CodeRabbit

  • Improvements

    • Binary message payloads are now encoded as base64 when sent and are conditionally decoded on receipt to ensure accurate transmission and reconstruction.
    • Configuration/schema includes an optional flag to mark payloads as base64, enabling interoperable handling across services.
  • Tests

    • Test expectations updated to assert concrete base64-encoded payloads to reflect the new encoding behavior.

@jzsfkzm jzsfkzm requested a review from a team as a code owner November 11, 2025 16:16
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 11, 2025

Walkthrough

The PR encodes frontend shell WebSocket payloads as base64 and adds isBase64: true; updates the backend proxy to decode when isBase64 is present; extends the provider request schema with isBase64?: boolean; and adjusts unit tests to expect base64 literals.

Changes

Cohort / File(s) Summary
Frontend — shell payload encoding
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts
Outbound shell messages now include isBase64: true and encode the payload as base64 (bytes → binary string → base64) instead of sending the raw string.
Backend — decoding & schema
apps/provider-proxy/src/services/WebsocketServer.ts, apps/provider-proxy/src/utils/schema.ts
WebsocketServer now decodes message.data from base64 when message.isBase64 is true, otherwise retains legacy parsing. providerRequestSchema gained optional isBase64?: boolean (default false) and the inferred ProviderRequestSchema now includes it.
Tests — updated expectations
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts
Tests updated to expect static base64 string literals for encoded shell payloads (replaced encoder-based expectations with known base64 values).

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant DeployWeb as Deploy Web (frontend)
    participant WS as WebSocket
    participant ProviderProxy as Provider Proxy (backend)
    participant Provider

    Client->>DeployWeb: send shell bytes
    DeployWeb->>DeployWeb: bytes → binary string → base64\nattach isBase64: true
    DeployWeb->>WS: send encoded payload (isBase64: true)
    WS->>ProviderProxy: deliver message
    rect rgb(240,245,255)
      Note over ProviderProxy: inspect message.isBase64
      alt isBase64 == true
        ProviderProxy->>ProviderProxy: decode base64 → bytes
      else isBase64 == false
        ProviderProxy->>ProviderProxy: legacy parse (split/charCode → bytes)
      end
    end
    ProviderProxy->>Provider: proxy reconstructed payload
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Review binary reconstruction in provider-proxy.service.ts and WebsocketServer.ts for multibyte correctness.
  • Verify schema default/validation and that isBase64 is optional and interoperable.
  • Confirm tests validate both base64 and legacy branches where relevant.

Possibly related issues

Possibly related PRs

Poem

🐰 Hopping bytes through moonlit space,
I tuck each nibble in base64 lace,
Frontend hums and wraps the song,
Backend decodes — it wasn't long,
Tiny rabbit cheers: payloads race! 🚀

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main feature being added: accepting base64 payloads during provider proxying.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d273898 and d54dc64.

📒 Files selected for processing (4)
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts (2 hunks)
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (2 hunks)
  • apps/provider-proxy/src/services/WebsocketServer.ts (1 hunks)
  • apps/provider-proxy/src/utils/schema.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
  • apps/provider-proxy/src/services/WebsocketServer.ts
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts
  • apps/provider-proxy/src/utils/schema.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Never use type any or cast to type any. Always define the proper TypeScript types.

Files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts
**/*.{js,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

**/*.{js,ts,tsx}: Never use deprecated methods from libraries.
Don't add unnecessary comments to the code

Files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts
🧬 Code graph analysis (1)
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1)
apps/deploy-web/src/utils/encoding.ts (1)
  • toBase64 (3-13)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: test-build
  • GitHub Check: validate / validate-app
  • GitHub Check: test-build
🔇 Additional comments (3)
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (3)

9-9: LGTM! Helper function import addresses past review feedback.

The import of toBase64 from the encoding utils is the correct approach and directly addresses the previous review comment requesting the use of this helper function instead of manual base64 encoding.


307-308: Correct addition of base64 flag for new encoding format.

The isBase64: true flag properly signals to the backend that the payload data will be base64-encoded, aligning with the schema extension in the provider-proxy service.


311-312: Excellent! Helper function resolves stack overflow concern.

Using toBase64(message) properly addresses the previous critical issue with spread operator stack overflow on large payloads. The helper function uses a robust implementation that safely handles Uint8Arrays of any size.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@codecov
Copy link

codecov bot commented Nov 11, 2025

Codecov Report

❌ Patch coverage is 60.00000% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 46.90%. Comparing base (371f5b2) to head (d54dc64).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
.../services/provider-proxy/provider-proxy.service.ts 50.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2201      +/-   ##
==========================================
- Coverage   47.24%   46.90%   -0.34%     
==========================================
  Files        1023     1013      -10     
  Lines       29105    28758     -347     
  Branches     7587     7562      -25     
==========================================
- Hits        13750    13489     -261     
+ Misses      15041    14886     -155     
- Partials      314      383      +69     
Flag Coverage Δ *Carryforward flag
api 81.99% <ø> (ø) Carriedforward from 371f5b2
deploy-web 25.98% <50.00%> (+<0.01%) ⬆️
log-collector ?
notifications 87.94% <ø> (ø) Carriedforward from 371f5b2
provider-console 81.48% <ø> (ø) Carriedforward from 371f5b2
provider-proxy 84.96% <100.00%> (ø)

*This pull request uses carry forward flags. Click here to find out more.

Files with missing lines Coverage Δ
...pps/provider-proxy/src/services/WebsocketServer.ts 85.78% <100.00%> (ø)
apps/provider-proxy/src/utils/schema.ts 93.54% <ø> (ø)
.../services/provider-proxy/provider-proxy.service.ts 85.37% <50.00%> (+0.61%) ⬆️

... and 68 files with indirect coverage changes

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f784754 and 1697b7b.

📒 Files selected for processing (3)
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1 hunks)
  • apps/provider-proxy/src/services/WebsocketServer.ts (1 hunks)
  • apps/provider-proxy/src/utils/schema.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Never use type any or cast to type any. Always define the proper TypeScript types.

Files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts
  • apps/provider-proxy/src/utils/schema.ts
  • apps/provider-proxy/src/services/WebsocketServer.ts
**/*.{js,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

**/*.{js,ts,tsx}: Never use deprecated methods from libraries.
Don't add unnecessary comments to the code

Files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts
  • apps/provider-proxy/src/utils/schema.ts
  • apps/provider-proxy/src/services/WebsocketServer.ts
🧬 Code graph analysis (2)
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1)
apps/indexer/drizzle/schema.ts (1)
  • message (530-576)
apps/provider-proxy/src/services/WebsocketServer.ts (1)
apps/indexer/drizzle/schema.ts (1)
  • message (530-576)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: validate / validate-app
  • GitHub Check: test-build
  • GitHub Check: test-build
🔇 Additional comments (2)
apps/provider-proxy/src/utils/schema.ts (1)

32-36: Temporary field is appropriately designed for gradual migration.

The optional isBase64 field with a default of false provides good backward compatibility during the transition period. Since the PR description mentions this will be removed in a follow-up change, consider adding a TODO comment or tracking issue reference to ensure the cleanup happens.

apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1)

306-307: LGTM! Base64 flag is correctly set for shell connections.

The isBase64: true flag properly indicates to the proxy that the payload will be base64-encoded, enabling the new encoding path while maintaining backward compatibility.

@jzsfkzm jzsfkzm force-pushed the feature/2178-base64-payloads branch from 425b8cd to d62c950 Compare November 12, 2025 00:59
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🧹 Nitpick comments (1)
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1)

311-312: Consider a loop-based approach for better performance on large payloads.

The current implementation correctly avoids the stack overflow issue from the previous spread operator approach. However, string concatenation in reduce creates intermediate string objects on each iteration, which can be slow for large payloads.

For better performance with large messages, consider using a traditional loop:

         if (message.length > 0) {
-          const binaryString = Array.from(message).reduce((acc, byte) => acc + String.fromCharCode(byte), "");
-          remoteMessage.data = btoa(binaryString);
+          let binaryString = '';
+          for (let i = 0; i < message.length; i++) {
+            binaryString += String.fromCharCode(message[i]);
+          }
+          remoteMessage.data = btoa(binaryString);
         }

Note: This is a micro-optimization that only matters for very large shell payloads (10MB+).

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 425b8cd and d62c950.

📒 Files selected for processing (4)
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts (2 hunks)
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1 hunks)
  • apps/provider-proxy/src/services/WebsocketServer.ts (1 hunks)
  • apps/provider-proxy/src/utils/schema.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • apps/provider-proxy/src/services/WebsocketServer.ts
  • apps/provider-proxy/src/utils/schema.ts
🧰 Additional context used
📓 Path-based instructions (3)
**/*.spec.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/no-jest-mock.mdc)

Don't use jest.mock() to mock dependencies in test files. Instead, use jest-mock-extended to create mocks and pass mocks as dependencies to the service under test.

**/*.spec.{ts,tsx}: Use setup function instead of beforeEach in test files
setup function must be at the bottom of the root describe block in test files
setup function creates an object under test and returns it
setup function should accept a single parameter with inline type definition
Don't use shared state in setup function
Don't specify return type of setup function

Files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts
**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

Never use type any or cast to type any. Always define the proper TypeScript types.

Files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts
**/*.{js,ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/general.mdc)

**/*.{js,ts,tsx}: Never use deprecated methods from libraries.
Don't add unnecessary comments to the code

Files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts
  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts
🧠 Learnings (1)
📚 Learning: 2025-07-21T08:24:27.953Z
Learnt from: CR
Repo: akash-network/console PR: 0
File: .cursor/rules/query-by-in-tests.mdc:0-0
Timestamp: 2025-07-21T08:24:27.953Z
Learning: Applies to apps/{deploy-web,provider-console}/**/*.spec.tsx : Use `queryBy` methods instead of `getBy` methods in test expectations in `.spec.tsx` files

Applied to files:

  • apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts
🧬 Code graph analysis (1)
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1)
apps/indexer/drizzle/schema.ts (1)
  • message (530-576)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: test-build
  • GitHub Check: validate / validate-app
  • GitHub Check: test-build
🔇 Additional comments (3)
apps/deploy-web/src/services/provider-proxy/provider-proxy.service.ts (1)

306-307: LGTM! isBase64 flag added to coordinate base64 payload handling.

The addition of isBase64: true correctly signals to the provider-proxy backend that the payload data is base64-encoded, enabling the conditional decoding logic.

apps/deploy-web/src/services/provider-proxy/provider-proxy.service.spec.ts (2)

945-945: LGTM! Test expectation correctly updated to base64-encoded value.

The test now expects the base64-encoded value "ZWNobyBoZWxsbw==" which correctly represents the encoding of "echo hello", matching the new base64 payload handling in the production code.


1018-1019: LGTM! Test expectations correctly updated to base64-encoded values.

The tests now expect the base64-encoded values "Zmlyc3Q=" and "c2Vjb25k" which correctly represent the encodings of "first" and "second", validating that multiple messages are properly base64-encoded.

@jzsfkzm jzsfkzm force-pushed the feature/2178-base64-payloads branch from d62c950 to d273898 Compare November 12, 2025 02:42
@jzsfkzm jzsfkzm force-pushed the feature/2178-base64-payloads branch from d273898 to d54dc64 Compare November 12, 2025 10:47
@stalniy stalniy merged commit 4efd4b6 into akash-network:main Nov 12, 2025
62 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments