Loading today’s stories
Build1 distinct publisher3 min readPublished
The endpoint keeps returning 200 with valid JSON, so release tooling reads an absent field and carries on. Pinning the version header defers that work rather than removing it, and the deferral has a date on it.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Start with the access path, because that decides whether you ever find out. In the 2026-03-10 payload the key is gone rather than set to null, according to the dev.to writeup by driftsignal [1][2]. A lookup that tolerates a missing key hands your code a falsy value and lets it continue. A lookup that treats a missing key as an error is the only shape of this bug that pages anybody.
Removal is the easy category. Two others in the same release are harder to catch. The remnants of the beta media type rename fields instead of dropping them, turning `user` into `owner` and `master_branch` into `default_branch` [9]. Same values, new keys, and a parser that finds nothing under the names it was written against. Separately, the languages enum in code scanning setup responses drops `javascript` and `typescript` in favour of a combined `javascript-typescript` [7]. That field is still present and still a valid string. A loose schema validator passes it. An equality check against `javascript` never matches again, and the branch behind it stops running.
The pin arithmetic is worth doing out loud. GitHub supports a previous version for at least 24 months after a new one ships, per the same post [10]. Twenty-four months from 2026-03-10 is 2028-03-10 [11]. That is a floor rather than your date, and it holds only if your pin sits on the version immediately before this one. Two versions back and your clock started earlier, so assume less time on it.
The audit that actually catches this class runs in three passes, in order:
1. Enumerate the response field names each consumer reads, per endpoint. The field name is the audit unit. The endpoint list is not fine-grained enough. 2. Replay recorded traffic with `X-GitHub-Api-Version` set to the new date [4] and diff key sets against your pinned responses. Diff keys, not values, because the values will look plausible. 3. Assert presence on the fields that gate an action. A deploy step that resolves a merge commit should refuse to run on an absent one instead of defaulting it.
`has_downloads` went out in this release after more than a decade of deprecation [6], which is a fair argument that a deprecation notice is not a delivery mechanism.
One caveat on the whole read. This comes from a single dev.to post, and the copy supplied breaks off mid-sentence in the section on what happens the day you take the bump [14]. The post also gestures at status code changes and endpoints moving work to the background without detailing them [13]. I would not schedule migration work off it alone. GitHub's own 2026-03-10 breaking changes list is the authority; the writeup is a good map of the failure mode, checked against the field names from step one.
Ranked by verification strength, evidence, and original report placement.
GitHub's REST API version 2026-03-10 removed the merge_commit_sha field from pull request responses across every endpoint that returns a pull request, including events, lists and single PR reads.
The removal produces no error: the endpoint still returns a 200 and a valid JSON object, and code reading the field gets null or undefined and continues.
GitHub versions its REST API by date and callers opt into a version with the X-GitHub-Api-Version header; the post calls this good practice on GitHub's part.
The singular assignee field is removed from Issues and Pull Requests; it duplicated the assignees array, and integrations reading issue.assignee will now conclude every issue is unassigned.
has_downloads is removed from Repository responses after more than a decade of deprecation, so code reading it gets undefined and branches take the wrong path.
The javascript and typescript values are removed from the languages enum in code scanning setup responses and replaced by a combined javascript-typescript, so equality checks and switches on javascript stop matching.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 3, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Your scanner finds it in seconds; the average fix now takes 252 days1 distinct publisher
security
Consuming a malware feed at GitHub's scale bills out in rip-outs and credential rotation1 distinct publisher
build
One API call decides whether your SHA pin still means what it says1 distinct publisher
security
Eight versions of glob in one repo produced a year of mostly unexploitable security alerts1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific enough to check, unchecked here
Every assertion is falsifiable within a minute — merge_commit_sha, the singular assignee, has_downloads, javascript-typescript, cvss_severities, user becoming owner — and that precision is the strongest thing this story has going for it. The weakness is provenance: one dev.to post reads GitHub's changelog for us without quoting or linking it, and the text stops mid-word inside the section that matters most, the one about the day you unpin.
No one visibly broken yet
What would make this measurable is a team that shipped to the wrong commit, a bot that commented the wrong SHA, a bug thread, a count of callers still pinned to the old header. None of that exists in our coverage. A dated API version being available is not uptake, and the failure mode described is by design invisible — which is the post's own point, and also the reason we cannot score it.
Headline runs ahead of the record
The underlying material is dry: documented field removals in a dated version you opt into by header, and the post says as much, crediting GitHub for handling it responsibly. The overshoot is in the harm — wrong deploys, 'genuinely dangerous' null severities in security workflows — presented as consequence with no case behind it, in a piece titled to say your automation will just be wrong. Mild, not egregious: the mechanism is real even where the damage is hypothetical.
The argument ends where a product begins
Follow the piece to its last line and it arrives at runtime monitoring of live responses — it literally cuts off mid-word on that phrase — and it is published on dev.to under an account named for drift, arguing that drift is the failure nobody catches. That does not make a single field name wrong. It does mean the framing, a documented changelog recast as a lurking hazard your tests cannot see, is precisely the framing that flatters the author's category, and no counter-case for the cost or noise of such monitoring is offered.
Trust the mechanism, verify the specifics
Two different levels of certainty are tangled together here. That deleting a field from a JSON body returns 200 and yields undefined downstream needs no sourcing at all — it is how HTTP and JSON work. Which fields, on which endpoints, from which dated version, and whether the support floor is really 24 months, all come from one uncorroborated reading of a document we cannot see, and any of them could be off by a version without anything in this story catching it.