fix(grpc): apply maxBodySizeMb to Dapr sidecar (--max-body-size)

[Siraddeen]

Summary

Fixes an issue where maxBodySizeMb was not correctly applied to the Dapr sidecar receive limit.

Changes

• Pass --max-body-size to daprd when maxRequestSizeMb is defined
• Preserve default behavior when not specified (4MB)

Tests

• Verified existing e2e grpc tests pass
• Confirmed payloads >4MB succeed when configured
• Confirmed payloads exceeding limit are rejected

Fixes #735

[WhitWaldo]

@Siraddeen Perhaps you're missing some commits, but I don't show any changes except to the test logic here.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 25.98%. Comparing base (d1bf38a) to head (4edbcb9).
⚠️ Report is 73 commits behind head on main.

Files with missing lines	Patch %	Lines
src/implementation/Client/GRPCClient/invoker.ts	0.00%	4 Missing ⚠️
src/implementation/Client/GRPCClient/GRPCClient.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##              main     #776       +/-   ##
============================================
- Coverage   100.00%   25.98%   -74.02%     
============================================
  Files            1      138      +137     
  Lines            6     3721     +3715     
  Branches         1      564      +563     
============================================
+ Hits             6      967      +961     
- Misses           0     2710     +2710     
- Partials         0       44       +44     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Siraddeen]

Thanks for the feedback.

The fix ensures that maxRequestSizeMb is correctly applied to the Dapr sidecar via --max-body-size, so both send and receive limits are aligned.

I’ve also added integration tests covering:

• Default behavior (4MB limit)
• Overridden behavior using maxBodySizeMb
• Validation for payloads exceeding configured limits

Please let me know if you'd like the fix split or adjusted further.

[Siraddeen]

Thanks for your patience.

I re-ran the full E2E gRPC test suite in a Linux environment (WSL) to match the CI setup, and all tests are now passing.

The issue I encountered earlier was due to local Windows networking differences rather than the implementation itself.

The fix ensures that maxBodySizeMb is correctly applied to the Dapr sidecar using --max-body-size, and the behavior is validated through integration tests covering both default and overridden limits.

Please let me know if you'd like any further adjustments.

[WhitWaldo]

This is the repository for just the JS SDK - we have no interaction with initializing the sidecar (except with regards to the sidecar we spin up for e2e testing). We don't need tests that validate that the runtime works with the flags - they have their own test suite that validates that.

Your fix seems to readily pass a missing parameter to the sidecar for testing purposes, which is great, because it means that E2E tests will pass, as you've observed. But they were already passing and this isn't what #735 reports.

#735 reports that when utilizing the service invocation methods (and perhaps others), the gRPC client in the SDK itself is not honoring a configured receive limit increase. Your PR doesn't change any of the SDK logic itself - just the test harness. While it might be a useful PR unto itself so the E2E tests properly work, you're not actually changing the SDK and fixing the reported issue.

Rather, if you'd like to take a stab at tackling #735, you're certainly invited to at which point I'd be happy to review this again.

[Siraddeen]

Updated the implementation to enforce maxBodySizeMb at the SDK level.

The validation is now performed in the gRPC invoker after serialization,
ensuring payload size is correctly limited before sending.

This aligns with the issue description, where the SDK itself should honor
the configured receive limit rather than relying on the sidecar behavior.