Skip to content

Remove the broken Stainless csharp target so spec PRs stop failing CI#663

Closed
ls-bolt[bot] wants to merge 1 commit into
mainfrom
07-07-remove-broken-stainless-csharp-target
Closed

Remove the broken Stainless csharp target so spec PRs stop failing CI#663
ls-bolt[bot] wants to merge 1 commit into
mainfrom
07-07-remove-broken-stainless-csharp-target

Conversation

@ls-bolt

@ls-bolt ls-bolt Bot commented Jul 7, 2026

Copy link
Copy Markdown

This PR has been claimed. The active PR is now #671.

Summary

Removes the csharp target from .stainless/stainless.yml so the Build SDKs for pull request / preview check stops failing on every spec-changing PR.

Why every spec PR is red: Stainless's csharp build CI is broken upstream for ANY freshly generated code (content-independent, proven by bisect on #650, breakage window ~Jul 3). The preview check gates on a per-language head-vs-base regression, and with csharp in main's config the base build resolves to a cached pre-breakage csharp success — so every fresh head failure counts as a regression → red.

Why this fixes it: with csharp out of the config on main, base builds have no cached csharp success to regress from — matching outcomes on base and head → "not a regression" → green. Proven end-to-end by probe #659: the exact previously-failing change class (doc-comment-only codegen delta) ran against a csharp-free base and preview passed. Full mechanics: investigation writeup.

No shipping impact: the csharp target is unpublished (production_repo: null, publish.nuget: false). Re-add the block when Stainless fixes their csharp build CI upstream.

Sequencing (for #657 and other open spec PRs)

  1. Merge this PR — its own preview will be red (its base is current main); merge through it (precedent: feat(openapi): add rail + settlement-timing fields to OutgoingTransaction #633, Add idType/identifier to IndividualCustomerCreateRequest (ENG-10686) #637).
  2. Merge/rebase main into open spec PRs (e.g. docs(cards): PAN reveal via POST /cards/{id}/reveal; panEmbedUrl off the Card resource #657) — their next preview run goes green.

Verification


🤖 thundering-graviton-3(#3) | Feedback

Stainless's csharp build CI fails on any freshly generated code
(content-independent, proven by bisect on #650), and the preview check
gates on head-vs-base regression per language — so every spec-changing
PR fails 'Build SDKs' while main's config still lists csharp and the
base build resolves to a cached pre-breakage success. With csharp gone
from the config on main, base builds have no csharp success to regress
from and the check passes (proven end-to-end by probe #659, which ran
the exact previously-failing change class against a csharp-free base
and passed).

The target is unpublished (production_repo: null, no NuGet publish), so
nothing ships differently. Re-add the block when Stainless fixes their
csharp build CI upstream.

This PR's own preview check will still be red (its base is current
main) — merge through it; precedent #633, #637.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 7, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Actions Updated (UTC)
grid-flow-builder Ignored Ignored Preview Jul 7, 2026 7:02pm
grid-wallet-demo Ignored Ignored Preview Jul 7, 2026 7:02pm

Request Review

@ls-bolt ls-bolt Bot added the bolt label Jul 7, 2026

akanter commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

This stack of pull requests is managed by Graphite. Learn more about stacking.

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

✱ Stainless preview builds for grid

This PR will update the grid SDKs with the following commit messages.

cli

chore(internal): regenerate SDK with no functional changes

csharp

feat: Remove the broken Stainless csharp target so spec PRs stop failing CI

go

chore(internal): regenerate SDK with no functional changes

kotlin

chore(internal): regenerate SDK with no functional changes

openapi

docs(api): remove C# code samples

php

chore(internal): regenerate SDK with no functional changes

python

chore(internal): regenerate SDK with no functional changes

ruby

chore(internal): regenerate SDK with no functional changes

typescript

chore(docs): remove C# language support from SDK examples

Edit this comment to update them. They will appear in their respective SDK's changelogs.

grid-cli studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️build ❗lint ❗test ❗

grid-openapi studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️

grid-ruby studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ⏭️ (prev: build ✅) → lint ✅test ✅

grid-go studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ⏭️ (prev: build ✅) → lint ❗test ❗

go get github.com/stainless-sdks/grid-go@80955f24bbecaad2904ea5654f4b0463d165c8b4
grid-typescript studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ✅lint ❗test ✅

npm install https://pkg.stainless.com/s/grid-typescript/e4966184e816d4aba9cd9d721739f95206e6ec8c/dist.tar.gz
grid-kotlin studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️build ⏭️ (prev: build ✅) → lint ⏭️ (prev: lint ✅) → test ❗

grid-csharp studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️build ❗lint ✅test ❗

grid-python studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ⏭️ (prev: build ✅) → lint ⏭️ (prev: lint ❗) → test ❗

grid-php studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅lint ✅test ✅


This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-07-07 19:07:16 UTC

@greptile-apps

greptile-apps Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR removes the unpublished C# SDK target from .stainless/stainless.yml to unblock spec-changing PRs whose Stainless preview check was failing due to a Stainless-side csharp build regression introduced around Jul 3.

  • The removed csharp block was fully unpublished (production_repo: null, publish.nuget: false), so no shipped SDK artifact is affected.
  • A comment replaces the block to explain the omission and serve as a breadcrumb for re-adding it once the upstream build issue is resolved.

Confidence Score: 5/5

Removing an unpublished, non-shipping SDK target from a code-generation config has no runtime or customer-facing impact.

The only changed file is the Stainless config, and the removed block was explicitly never published (nuget disabled, no production repo). The remaining targets and all API resource definitions are untouched. The explanatory comment is accurate and leaves a clear path for restoration.

No files require special attention.

Important Files Changed

Filename Overview
.stainless/stainless.yml Removes the unpublished csharp target block (edition, package_name, production_repo, publish.nuget) and replaces it with an explanatory comment; no other targets or settings are modified.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Spec-changing PR opened] --> B[Stainless preview check runs]
    B --> C{Base build: csharp in config?}
    C -- Before this PR: YES --> D[Base resolves cached pre-breakage\ncsharp SUCCESS]
    D --> E[Head build: fresh csharp FAIL]
    E --> F{Regression?}
    F -- SUCCESS → FAIL = YES --> G[❌ preview check RED]
    C -- After this PR: NO --> H[Base has no csharp result to compare]
    H --> I[Head build: no csharp run]
    I --> J{Regression?}
    J -- no baseline = NO regression --> K[✅ preview check GREEN]
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[Spec-changing PR opened] --> B[Stainless preview check runs]
    B --> C{Base build: csharp in config?}
    C -- Before this PR: YES --> D[Base resolves cached pre-breakage\ncsharp SUCCESS]
    D --> E[Head build: fresh csharp FAIL]
    E --> F{Regression?}
    F -- SUCCESS → FAIL = YES --> G[❌ preview check RED]
    C -- After this PR: NO --> H[Base has no csharp result to compare]
    H --> I[Head build: no csharp run]
    I --> J{Regression?}
    J -- no baseline = NO regression --> K[✅ preview check GREEN]
Loading

Reviews (1): Last reviewed commit: "Remove the broken Stainless csharp targe..." | Re-trigger Greptile

@benwgold benwgold deleted the 07-07-remove-broken-stainless-csharp-target branch July 8, 2026 17:18
benwgold added a commit that referenced this pull request Jul 8, 2026
…#671)

## Summary

Removes the csharp target from `.stainless/stainless.yml` so the `Build
SDKs for pull request / preview` check stops failing on every
spec-changing PR.

**Why every spec PR is red**: Stainless's csharp build CI is broken
upstream for ANY freshly generated code (content-independent, proven by
bisect on #650, breakage window ~Jul 3). The preview check gates on a
per-language head-vs-base regression, and with csharp in main's config
the base build resolves to a cached pre-breakage csharp *success* — so
every fresh head failure counts as a regression → red.

**Why this fixes it**: with csharp out of the config on main, base
builds have no cached csharp success to regress from — matching outcomes
on base and head → "not a regression" → green. Proven end-to-end by
probe #659: the exact previously-failing change class (doc-comment-only
codegen delta) ran against a csharp-free base and `preview` **passed**.
Full mechanics: [investigation
writeup](#657 (comment)).

**No shipping impact**: the csharp target is unpublished
(`production_repo: null`, `publish.nuget: false`). Re-add the block when
Stainless fixes their csharp build CI upstream.

## Sequencing (for #657 and other open spec PRs)

1. Merge this PR — **its own `preview` will be red** (its base is
current main); merge through it (precedent: #633, #637).
2. Merge/rebase main into open spec PRs (e.g. #657) — their next
`preview` run goes green.

## Verification

- `make lint` passes; the file matches the exact removal previously
validated on the #657 branch (commit 069ad9a) and by probe #659.

---
🤖
[thundering-graviton-3](https://zeus.dev.dev.sparkinfra.net/#/arc?id=thundering-graviton)[(#3)](https://zeus.dev.dev.sparkinfra.net/#/instance?id=thundering-graviton-3)
| [Feedback](https://zeus.dev.dev.sparkinfra.net/feedback)

Original PR: #663

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
benwgold added a commit that referenced this pull request Jul 8, 2026
…the Card resource (#657)

## Summary

Follow-up #2 from
[webdev#29877](lightsparkdev/webdev#29877)
(Lithic card PAN-reveal POC), evolved per review: PAN reveal is now an
**explicit, dedicated endpoint** rather than a side effect of reading
the card. Server change:
[webdev#29995](lightsparkdev/webdev#29995).

- **New `POST /cards/{id}/reveal`**
(`openapi/paths/cards/cards_{id}_reveal-session.yaml` +
`CardRevealResponse` schema) — mints a signed, short-lived reveal URL
and returns `{ panEmbedUrl, expiresAt }`. Every mint is audit-logged
with the requesting actor; unattributable sessions get 403.
- **`panEmbedUrl` is removed from the `Card` schema entirely** —
get/list/create/update responses and webhook payloads never carry it. A
live PAN-reveal credential only exists when a client explicitly asked
for one (least-privilege + clean "reveal requested" audit semantics).
- **Docs rewritten to the reveal-session flow**: issuing-cards gains the
`POST …/reveal` example, quickstart/webhooks/terminology snippets
updated, webhook examples no longer show the field, and `GET
/cards/{id}` points at the reveal endpoint.
- **Rode along from the folded #656**: a small `GtqAccountInfoBase`
description clarification. `.stainless/stainless.yml` is byte-identical
to main (the csharp experiments were fully reverted; the real csharp fix
is #663).

## Verification

- `make build` + `make lint` pass (0 errors; remaining warnings
pre-exist on main).
- Server implementation is TDD'd end-to-end on
[webdev#29995](lightsparkdev/webdev#29995) (58
handler/proxy tests + dashboard dialog tests green).

## CI note — red `preview` check is expected until #663 merges

The Stainless csharp target's upstream build CI fails on any codegen
delta (content-independent); the fix is #663 (removes the unpublished
csharp target on main). Until it merges, `preview` stays red on
spec-changing PRs, this one included — merge through it (precedent #633,
#637). Details:
[investigation](#657 (comment)).

---
🤖
[thundering-graviton-5](https://zeus.dev.dev.sparkinfra.net/#/arc?id=thundering-graviton)[(#5)](https://zeus.dev.dev.sparkinfra.net/#/instance?id=thundering-graviton-5)
| [Feedback](https://zeus.dev.dev.sparkinfra.net/feedback)

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: mohamedwane <mohamedwane@users.noreply.github.com>
Co-authored-by: benwgold <benwgold@users.noreply.github.com>
Co-authored-by: pengying <pengying@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants