| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
chore(billing): retire the HTTP billing events sent to Orb (NAN-6503) (#7427) - **Stop emitting billing events to Orb over HTTP.** Removes the five realtime emissions in the metering usage processor (MAR, actions, function executions, proxy, webhook forwards) and the three hourly cron emissions (`records`, `billable_connections_v2`, and the legacy `billable_connections`). Canonical billing has been fed exclusively by the ClickHouse → S3 export since the Aug 1 cutover, so this only removes the `_http` shadow stream — roughly 6–8M Orb API writes a day that nothing reads. - **Drop the cutover seam from the S3 export**, which now always emits canonical event names rather than deriving them from `BILLING_EVENTS_CUTOVER_AT`. The env var's own comment asked for this once the HTTP path was retired. - **Delete the ingestion path that is now dead**: `Billing.add`/`shutdown`/`ingest`, `BillingClient.ingest`, the batcher grouping strategy, `toOrbEvent`, the `BillingEvent` type union, the `ORB_BILLING_EVENTS_INGESTED` metric, the `BILLING_INGEST_*` and `ORB_RETRY_*` env vars, the pro-rated `connectionService.billableConnections` query, and an unused `uuidv7` dependency. Covers two of the four items on [NAN-6503 — Deprovision HTTP ORB events](https://linear.app/nango/issue/NAN-6503/deprovision-http-orb-events): removing the code that sends HTTP events, and removing the suffix machinery. The other two are outside the repo and still open — deleting the temporary `_http` billable metrics in Orb, and the cutover monitors. ## Why this is safe now All three deployed environments are past their cutover instant (production 2026-08-01, staging and development 2026-07-10). Since that moment `toOrbEvent` has suffixed every HTTP event `_http` with no exceptions, so the canonical event names that customer plans filter on have been S3-fed only, for 37 days in production with zero failed export runs in the last 30. The legacy `billable_connections` has had no canonical counterpart at all over that window, which is why its query goes too. A mixed-version rollout is a no-op: old and new pods compute the same S3 object key, and the export is already guarded by a `HeadObject` skip plus a distributed lock, so neither duplicate objects nor double billing are reachable. The removed env vars stay set in the deployments after this ships. The env schema strips unknown vars rather than rejecting them, so pods still boot — verified with a throwaway test rather than assumed. ## Test plan - [x] `ts-build`, `lint`, and `format:check` clean; every package tsconfig includes `lib/**/*`, so test files are typechecked too - [x] Full unit suite: 4332 tests across 329 files - [x] Integration: metering (11, including the S3 export) and every billing-touching server suite under `v1/plans` plus spend alerts (176) - [x] Repo-wide grep across all file types confirms no remaining reference to any removed symbol or env var - [x] Confirmed no Datadog monitor reads `nango.billing.orb.ingested` - [x] Deliberately broke the exported event name and confirmed three integration tests go red - [ ] Deploy to development and confirm `nango.billing.orb.ingested` drops to zero - [ ] Confirm the S3 export still writes canonical object keys in development - [ ] Confirm `nango.connections.count` and `nango.records.total.*` still report — these back the `[Billing] Connections/Records - LOW` monitors - [ ] Heads-up to Thomas: the `nango.billing.orb.ingested` widget on his dashboard will go permanently no-data 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7427?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 14 小时前 | |
chore(billing): retire the HTTP billing events sent to Orb (NAN-6503) (#7427) - **Stop emitting billing events to Orb over HTTP.** Removes the five realtime emissions in the metering usage processor (MAR, actions, function executions, proxy, webhook forwards) and the three hourly cron emissions (`records`, `billable_connections_v2`, and the legacy `billable_connections`). Canonical billing has been fed exclusively by the ClickHouse → S3 export since the Aug 1 cutover, so this only removes the `_http` shadow stream — roughly 6–8M Orb API writes a day that nothing reads. - **Drop the cutover seam from the S3 export**, which now always emits canonical event names rather than deriving them from `BILLING_EVENTS_CUTOVER_AT`. The env var's own comment asked for this once the HTTP path was retired. - **Delete the ingestion path that is now dead**: `Billing.add`/`shutdown`/`ingest`, `BillingClient.ingest`, the batcher grouping strategy, `toOrbEvent`, the `BillingEvent` type union, the `ORB_BILLING_EVENTS_INGESTED` metric, the `BILLING_INGEST_*` and `ORB_RETRY_*` env vars, the pro-rated `connectionService.billableConnections` query, and an unused `uuidv7` dependency. Covers two of the four items on [NAN-6503 — Deprovision HTTP ORB events](https://linear.app/nango/issue/NAN-6503/deprovision-http-orb-events): removing the code that sends HTTP events, and removing the suffix machinery. The other two are outside the repo and still open — deleting the temporary `_http` billable metrics in Orb, and the cutover monitors. ## Why this is safe now All three deployed environments are past their cutover instant (production 2026-08-01, staging and development 2026-07-10). Since that moment `toOrbEvent` has suffixed every HTTP event `_http` with no exceptions, so the canonical event names that customer plans filter on have been S3-fed only, for 37 days in production with zero failed export runs in the last 30. The legacy `billable_connections` has had no canonical counterpart at all over that window, which is why its query goes too. A mixed-version rollout is a no-op: old and new pods compute the same S3 object key, and the export is already guarded by a `HeadObject` skip plus a distributed lock, so neither duplicate objects nor double billing are reachable. The removed env vars stay set in the deployments after this ships. The env schema strips unknown vars rather than rejecting them, so pods still boot — verified with a throwaway test rather than assumed. ## Test plan - [x] `ts-build`, `lint`, and `format:check` clean; every package tsconfig includes `lib/**/*`, so test files are typechecked too - [x] Full unit suite: 4332 tests across 329 files - [x] Integration: metering (11, including the S3 export) and every billing-touching server suite under `v1/plans` plus spend alerts (176) - [x] Repo-wide grep across all file types confirms no remaining reference to any removed symbol or env var - [x] Confirmed no Datadog monitor reads `nango.billing.orb.ingested` - [x] Deliberately broke the exported event name and confirmed three integration tests go red - [ ] Deploy to development and confirm `nango.billing.orb.ingested` drops to zero - [ ] Confirm the S3 export still writes canonical object keys in development - [ ] Confirm `nango.connections.count` and `nango.records.total.*` still report — these back the `[Billing] Connections/Records - LOW` monitors - [ ] Heads-up to Thomas: the `nango.billing.orb.ingested` widget on his dashboard will go permanently no-data 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7427?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 14 小时前 | |
feat(ui): Billing show usage (#3992) ## Changes Fixes https://linear.app/nango/issue/NAN-3182/show-usage-in-billing-page - Show usage in Billing page It's pretty basic but that's the VIP [figma](https://www.figma.com/design/41nuXTFjGrBmjRW07QF4r7/Billing?node-id=2090-2878&t=W0GURn4clsFn7dYv-0) Only available to Growth plan rn ## 🧪 Tests - You need an user in Orb (test mode) - And a subscription - And a non-free plan in plans' table  <!-- This is an auto-generated description by mrge. --> --- ## Summary by mrge Added a usage table to the Billing page to show current and previous month usage for each billable metric. - **New Features** - Added backend API to fetch current and previous usage. - Displayed usage data in a table on the Billing page. <!-- End of auto-generated description by mrge. --> <!-- Summary by @propel-code-bot --> --- **Billing Page Usage Information Enhancement** This PR adds usage information to the Billing page, allowing users on the Growth plan to view their current and previous month's usage metrics. The implementation includes new backend API endpoints to fetch usage data from the billing provider (Orb), and UI components to display this information in a table format. The feature helps customers understand their resource consumption. **Key Changes:** • Created a new endpoint to fetch current and previous month usage data • Restructured billing interfaces by moving types to a common package • Added ``UI`` components to display usage metrics in a table • Enhanced `OrbClient` with methods to fetch customer, subscription, and usage info • Added `Manage Billing` button linking to Orb customer portal **Affected Areas:** • Billing ``API`` in server package • Billing ``UI`` components in webapp package • Type definitions across multiple packages • Orb client implementation **Potential Impact:** **Functionality**: Adds visibility into resource usage for Growth plan users, providing them with metrics about their consumption both for current and previous months **Performance**: Minimal impact. Usage data is cached for 60 seconds on Orb's side to reduce API load **Security**: No significant security implications as this is a read-only feature **Scalability**: Low impact as the feature uses the existing Orb billing infrastructure **Review Focus:** • Error handling in the new ``API`` endpoints and client methods • Type safety across package boundaries • Caching strategy for billing data • ``UI`` responsiveness and error states <details> <summary><strong>Testing Needed</strong></summary> • Verify that usage data is correctly displayed for Growth plan users • Test with various usage patterns to ensure the table displays correctly • Verify that previous month's data is accurately shown • Check that the Manage Billing button correctly links to Orb's customer portal • Verify that the feature is only available to Growth plan users </details> <details> <summary><strong>Code Quality Assessment</strong></summary> **packages/billing/lib/clients/orb.ts**: Contains optional chaining without proper array existence checks and unnecessary non-null assertions **packages/webapp/src/hooks/usePlan.tsx**: QueryKey in useApiGetUsage should include env parameter for proper cache invalidation **packages/types/lib/billing/types.ts**: BillingUsageMetric lacks unit field for better metric visualization **packages/server/lib/controllers/v1/plans/usage/getUsage.ts**: Good error handling but lacks detailed error messages </details> <details> <summary><strong>Best Practices</strong></summary> **Type Safety**: • Moving types to a common package • Using Result type for error handling **API Design**: • Consistent ``API`` structure • Proper error responses **Performance**: • Using Orb's caching mechanism to reduce ``API`` calls </details> <details> <summary><strong>Possible Issues</strong></summary> • Error handling in billing API calls could be improved • Feature availability is checked in both frontend and backend • The error messages in API failures could be more specific • Missing proper caching strategy in the frontend (queryKey issue) </details> --- *This summary was automatically generated by @propel-code-bot* | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 14 小时前 | ||
| 14 小时前 | ||
| 1 年前 |