## What this does
Fixes an open redirect plus a handful of small, mostly-invisible
hardening changes around it.
## What's in it
- **The fix**: trailing-slash redirects no longer let `//evil.com/`
redirect off-host.
- **SSRF block** on the DNS/HTTP namespace verification — refuses to
dial loopback, RFC1918, link-local, multicast, CGNAT, or
IP-literal/single-label \"domains\".
- **Slow-client guard**: `ReadTimeout` and `IdleTimeout` on the HTTP
server (no `WriteTimeout` — would risk cutting off legitimate
multi-package publishes).
- **Defence-in-depth headers** on the UI (`/`) and 404 responses.
- **5xx responses** stop leaking raw DB error text to clients (logged
server-side instead).
- **Search filter** stops treating `%` and `_` as wildcards.
- **Validators**: PyPI/NuGet identifiers URL-escaped before fetching;
MCPB no longer follows redirects.
- **Misc**: `Version` field bounded to 255 chars; logs quote user input;
`BlockedNamespaces` denylist now catches subdomain claimants.
Each change is its own commit so they can be reviewed (or reverted)
independently.
## Test plan
- [ ] CI green
- [ ] Synthetic publish in staging for each package type (npm, pypi,
nuget, oci, mcpb) — confirms validator changes don't regress
- [ ] Quick browser check of `/` after deploy to confirm UI still loads
with the new CSP
- [ ] `curl https://<host>//evil.com/` — confirm the open redirect is
closed
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.4](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.4)
(#1225) to production: registry pod memory request `256Mi → 512Mi`,
limit `512Mi → 1Gi`.
## Why
#1221 doubled pgxpool `MaxConns` 30→60 per pod without bumping the
registry pod memory limit. pgxpool keeps per-connection state in the Go
process (prepared statement cache, scratch buffers, row iteration state)
so peak per-pod memory shifted from ~330 MB to ~450 MB against the 512
MiB limit. Pod `tx49f` was OOMKilled at 17:01 UTC on 2026-04-29.
## Validation so far
- Staging deployed cleanly via `deploy-staging.yml` after #1225 merged
- Both staging pods running with `req=512Mi limit=1Gi` ✓
- Rolling update was clean — no failed health checks during the
transition
- Both pods spread across nodes (q716 + 7exo)
## Deployment
**Zero downtime** — Deployment template change only, rolling update with
`maxSurge: 1, maxUnavailable: 0`. No PG involvement (no
`max_connections` change, no shared_preload_libraries change).
## Test plan
- [x] v1.7.4 release built and pushed
(`ghcr.io/modelcontextprotocol/registry:1.7.4`)
- [x] Staging deployed cleanly with new limits
- [ ] Prod Pulumi run applies cleanly; rolling update completes
- [ ] Prod pods come up with `req=512Mi limit=1Gi`
- [ ] After 24h: no OOMKills on either pod, peak memory stays under ~600
MB
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Follow-up to #1221. That PR doubled pgxpool `MaxConns` from 30 to 60 per
pod without bumping the registry pod memory limit. pgxpool keeps
per-connection state in the Go process (prepared statement cache,
scratch buffers, row iteration state), so memory grew roughly
proportionally — peak per-pod usage shifted from ~330 MB to ~450 MB
against a 512 MiB limit.
## What surfaced it
Pod `tx49f` was OOMKilled at 17:01 UTC on 2026-04-29 (`exitCode 137`,
`reason: OOMKilled`). Memory history from Cloud Monitoring confirms the
regression:
| Pods | Peak 30-min memory |
|------|-------------------:|
| Pre-#1221 (`MaxConns=30`) | 178–333 MB |
| **Post-#1221** (`MaxConns=60`) | **437–449 MB** |
| Old limit | **512 MiB** ← right at the edge |
Other pod was at 394 MB at the time of inspection — could OOM again.
## Fix
`deploy/pkg/k8s/registry.go:217-225`:
| | Before | After |
|---|-------:|------:|
| `requests.memory` | 256 MiB | **512 MiB** |
| `limits.memory` | 512 MiB | **1 GiB** |
1 GiB is ~2× the current peak under load — gives room for traffic spikes
without immediate OOM risk. Either node has 4–5 GiB free allocatable
memory, so the new request fits comfortably.
## Test plan
- [x] `go build ./...` clean
- [x] `golangci-lint run` clean
- [ ] After release + prod promotion: pod memory stabilises around 450
MB peak with no OOMKills
- [ ] After release + prod promotion: tx49f restartCount stops climbing
(currently at 5)
## Deployment
Zero downtime — Deployment template change only, rolling update with
`maxSurge: 1, maxUnavailable: 0`. **No PG involvement** (no
`max_connections` change, no shared_preload_libraries change). Same
shape as a normal v1.7.x image promotion.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.3](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.3)
to production. Contents:
- **#1220** — `RemoteURL` filter SQL rewritten to use JSONB containment
(`@>`) instead of `EXISTS jsonb_array_elements`. The new form is
GIN-indexable; the old form forced a full table scan. Local benchmark:
40,398 → 294 buffer reads, 17 ms → 1.6 ms. Maps to prod's 10,005 ms
cold-cache observation.
- **#1221** — pgxpool `MaxConns 30→60`, `MinConns 5→10`. PG
`max_connections 100→200`. Explicit PG `resources:` block (was unset).
## What this addresses
- **#1220**: yesterday's 17:08 UTC `Publish Endpoint Latency` alert
(`dev.storage/mcp` publish took 14.8s with `remotes_ms=10980` —
pinpointed by the per-phase slog from #1215).
- **#1221**: yesterday's 17:35–17:40 UTC `Availability dropped below
95%` alert and 18:17 UTC `Publish Endpoint Latency` re-fire. Both were
scraper-driven concurrency on `/v0/servers` (~15 req/s sustained from
ServiceNow + others). With the bumped pool, the queue at the Go HTTP
layer should clear faster instead of blowing up to 20–35s nginx-level
latencies.
## Deployment caveat
The PG `max_connections` change is a postmaster-level setting → CNPG
triggers a PG restart on the next prod Pulumi run. With `instances: 1`
this is brief downtime — staging took **~30s** during the equivalent
restart, with **one registry pod bouncing once** on its 8-attempt
DB-retry budget before recovering on the next kubelet restart.
**Time the merge for a low-traffic UTC window.** Alert history suggests
very early UTC (02:00–04:00) is quietest.
## Resource impact
PG node memory is currently 39% (~2.4 GiB / 6 GiB allocatable).
Worst-case PG memory growth with `max_connections=200` lands around 3–4
GiB, putting the node at ~65% — fits with headroom. Empirically, prod PG
has peaked at **413 MiB** in the last 30h of incident data, so the
proposed 4 GiB limit is ~10× the historical max — guardrail not
constraint.
## Post-merge
CNPG handles `pg_stat_statements` extension creation automatically (no
manual `CREATE EXTENSION` step needed — it was already done in v1.7.2's
deploy).
Verify after deploy:
```bash
PATH=/opt/homebrew/share/google-cloud-sdk/bin:$PATH
# max_connections actually changed
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -tAc "SHOW max_connections" # expect: 200
# resources block applied
kubectl get pod registry-pg-1 \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-o jsonpath='{.spec.containers[?(@.name=="postgres")].resources}{"\n"}'
# pgxpool MaxConns reflected (registry app uses 60 per pod after restart)
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -tAc "SELECT count(*) FROM pg_stat_activity WHERE datname='app'"
```
## Test plan
- [x] v1.7.3 release built and pushed
(`ghcr.io/modelcontextprotocol/registry:1.7.3`)
- [x] Staging deployed cleanly; PG restarted and came back with
`max_connections=200`; one staging pod bounced as expected
- [ ] Prod Pulumi run applies cleanly; brief PG restart
- [ ] Confirm `SHOW max_connections` returns 200 on prod
- [ ] Confirm `publish complete` events show `remotes_ms` < 10ms
- [ ] Watch for any "too many connections" errors during the rollout
window (none expected — Pulumi orders CNPG cluster before Deployment, so
PG accepts the new conn limit before pgxpool tries to use it)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Follow-up to #1215 and #1220. Both of those addressed *individual* slow
queries; this PR addresses *concurrency* — under today's scraper load
the cursor query is fast on average (mean 42ms) but the connection pool
saturates and queue depth blows up at the Go HTTP layer.
## Diagnosis
`pg_stat_statements` (added in #1215) made this possible to see:
```
max_ms mean_ms calls template
10,755 41.8 94,009 plain cursor pagination, no filter
7,277 214.7 14,770 ILIKE substring filter
7,638 330.8 7,656 ILIKE substring + is_latest filter
```
Mean times are healthy. But `max_exec_time` of 7–10s on the cursor
query, combined with sustained ~15 req/s from scrapers (ServiceNow's
148.139.x.x range, anonymous `node` user-agent, etc) saturates
`MaxConns=30 × 2 pods = 60`. New requests queue at the Go HTTP layer;
nginx-side p99 hits 35s; eventually scrapers time out at 60s, retry, and
amplify the queue.
Today's two ongoing alerts are both this pattern:
- 17:35–17:40 UTC `Availability dropped below 95%` — 4,526 GET requests
in 5 min, hundreds of 504s
- 18:17 UTC `Publish Endpoint Latency` re-fire — same scraper
concurrency dragging the publish path
Critically, the symptoms today were also visible during yesterday's
incident, but yesterday's broken cursor (#1215) was the dominant cause.
After #1215 the cursor is fast individually; concurrency now becomes the
next bottleneck.
## Changes
### pgxpool (`internal/database/postgres.go`)
| Setting | Before | After |
|---------|-------:|------:|
| `MaxConns` | 30 | **60** per pod |
| `MinConns` | 5 | **10** per pod |
| `MaxConnIdleTime` | 30 min | (unchanged) |
| `MaxConnLifetime` | 2 h | (unchanged) |
2 pods × 60 = 120 total app connections. Cuts queue depth roughly in
half at current scraper load.
### PG cluster (`deploy/pkg/k8s/postgres.go`)
- `max_connections: 100 → 200` — required to support the larger pool.
120 (app) + ~10 (PG internals: autovacuum, replication, admin) + 70
headroom.
- Added explicit `resources:` block — previously the pod had no resource
limits, making node-level OOM behaviour unpredictable.
| | Request | Limit |
|---|--------:|------:|
| memory | 512Mi | **4Gi** |
| cpu | 200m | 1500m |
## Resource budget
| Node | Now | After |
|------|----:|------:|
| dy89 (PG node) | 39% mem (~2.4 GiB / 6 GiB) | ~65% mem worst-case
(~3.9 GiB) |
| 2yxm | 36% mem | unchanged |
Both nodes well within capacity. CPU usage <50% on both, plenty of
headroom.
PG worst-case memory math:
- 200 conns × ~15 MB per backend = 3 GiB
- + `shared_buffers` 128 MiB
- + `maintenance_work_mem`, OS overhead, etc.
- ≈ 3–4 GiB total
## Deployment caveat
`max_connections` is a postmaster-level setting → CNPG triggers a PG
restart on the change. Same in-pod restart shape as the
pg_stat_statements deploy yesterday — registry pods see ~30s of DB
unavailability, covered by v1.7.1's retry-with-backoff (8 attempts, 1→8s
capped). One registry pod may bounce once before recovering, like
yesterday.
**Time the merge for a low-traffic UTC window.**
Order of operations matters within the deploy itself:
1. Pulumi applies the new CNPG spec → PG restarts with
`max_connections=200`
2. Rolling deploy of registry pods picks up `MaxConns=60` config
3. New conns are accepted up to 200 limit
Pulumi's standard ordering does step 1 before step 2 in this scenario
(Pulumi resource graph: CNPG cluster precedes Deployment). If for any
reason it doesn't, the worst case is `too many connections` errors
during a small window — Self-correcting once the rollout completes.
## Test plan
- [x] `go build ./...` clean for app + deploy
- [x] `make lint` clean
- [x] `go test -race ./internal/database/...` green
- [ ] On merge: staging deploy applies the spec change cleanly; PG
restarts; pool reaches 60 max
- [ ] On prod deploy: same; verify no `too many connections` errors
during the rollout window
- [ ] After deploy: query `SHOW max_connections` returns 200; query
pg_stat_statements after a scraper burst, confirm `max_exec_time` for
cursor query no longer hits 10s
## Out of scope
- **ILIKE substring search** (`server_name ILIKE '%foo%'`) is
unindexable. Three pg_stat_statements variants run with means 141–333ms
and max 4–7s. Worth replacing with a `pg_trgm` GIN index or full-text
search in a separate PR.
- **Per-IP nginx rate limiting** — defends against scraper retry storms
regardless of pool size.
- **`Cache-Control` on `/v0/servers`** — let nginx absorb
scraper-repeated cursors.
- **Pre-existing `superfluous WriteHeader` warnings** — separate Huma
framework issue.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Same shape of bug as #1215's cursor fix, different filter. The RemoteURL
filter built its WHERE predicate using `jsonb_array_elements` + `->>`
extraction, which the planner can't translate into a GIN search.
Replaced with a JSONB containment predicate `@>` that uses
`idx_servers_json_remotes`.
## Diagnosis (from the per-phase publish slog #1215 added)
Today's first publish-latency alert at 17:08 UTC pointed straight at
this:
```
publish complete server_name=dev.storage/mcp version=1.10.1 total_ms=14822
validate_ms=0 lock_ms=238 remotes_ms=10980 version_checks_ms=535 unmark_ms=3014 create_ms=53
```
`remotes_ms=10,980` on a server with **one** remote URL pointed at
`validateNoDuplicateRemoteURLs`, which runs the RemoteURL filter against
the database. EXPLAIN ANALYZE on prod confirmed:
```
Filter: (status != 'deleted') AND EXISTS(SubPlan 1)
Rows Removed by Filter: 21,092 ← scans the whole table
Buffers: shared hit=20,028
Execution Time: 10,005 ms
```
## Fix
`internal/database/postgres.go:99` rewritten:
```sql
-- before (planner can't use GIN index for this)
EXISTS (SELECT 1 FROM jsonb_array_elements(value->'remotes') AS remote
WHERE remote->>'url' = $1)
-- after (GIN-indexable)
value -> 'remotes' @> jsonb_build_array(jsonb_build_object('url', $1::text))
```
Semantically equivalent for our schema (`url` is always a string, NOT
NULL).
## Local benchmark — 20K rows, prod-shaped JSONB (~1KB/row)
| Form | Buffer hits | Index used | Time |
|------|------------:|------------|-----:|
| OLD | 40,398 | none — full scan | 17.0 ms |
| NEW | **294** | **`idx_servers_json_remotes` GIN bitmap** | **1.6 ms**
|
Maps to prod's 10,005 ms cold-cache observation — same shape of speedup
we got from the cursor fix.
## Scope honesty
This PR addresses the **publish slowness path**
(`validateNoDuplicateRemoteURLs` in the publish transaction). It
directly resolves today's 17:08 UTC `Publish Endpoint Latency` alert.
It does **not** address:
- Today's 17:35–17:40 UTC `Availability dropped below 95%` alert.
Per-investigation: only 4 publishes happened in the entire 17:00–17:50
window and zero during the burst minutes — so my initial "concurrent
slow publishes starved the pool" hypothesis was wrong. The actual cause
was scraper-driven concurrency (4,500+ requests in 5 min) on plain
cursor pagination + ILIKE substring search, where individual queries are
fast (mean 42 ms) but tail latency under concurrency reaches 10 s
server-side and 20–35 s nginx-level due to pool queueing.
- The 18:17 UTC `Publish Endpoint Latency` re-fire (same scraper-driven
concurrency).
A follow-up PR will raise pool size + PG `max_connections` + add
explicit PG resource limits to absorb concurrency without queue blowup.
That fix has a different shape (config) and a different risk profile (PG
restart for `max_connections`); kept separate so this surgical SQL
change can ship cleanly.
## Test plan
- [x] `go build ./...` clean
- [x] `make lint` clean
- [x] `go test -race ./internal/database/... ./internal/service/...`
green — existing `TestPostgreSQL_ListServers/filter by remote URL`
covers semantic correctness
- [x] EXPLAIN ANALYZE comparison locally on 20K rows + prod-shaped JSONB
- [ ] After merge + deploy: verify on prod via `EXPLAIN ANALYZE`;
confirm `remotes_ms` in `publish complete` slog drops to single-digit ms
## Out of scope (separate follow-ups)
- pgxpool `MaxConns` / `MinConns` bump + PG `max_connections` raise + PG
`resources` limits — addresses the cursor-tail and ILIKE-search
concurrency that this PR doesn't touch
- Per-IP rate limiting at nginx — defends against scraper retry storms
regardless of query speed
- `Cache-Control` headers on `/v0/servers` — let nginx absorb scraper
repeats
- Pre-existing `superfluous WriteHeader` warnings — separate Huma
framework issue
- ILIKE substring search on `server_name` is unindexable — could be
replaced with `pg_trgm` GIN index or full-text search
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.2](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.2)
(PR #1215) to production:
- **Row-constructor cursor pagination** — fixes the 760ms list query
that was the root cause of today's pool-exhaustion alerts. Local
benchmark shows /v0/servers paginated requests dropping from ~30ms (cold
cache, 100K rows) to ~0.05ms.
- **Per-phase publish slog** — `publish complete` events now include
validate / lock / remotes / version_checks / unmark / db_create timings
so the next slow publish is self-diagnostic.
- **pg_stat_statements** — aggregate query visibility we didn't have
during today's incident.
## Deployment caveat
The CNPG cluster spec change for `pg_stat_statements` triggers an in-pod
postgres restart on the next prod Pulumi run. Staging took **~45–70s of
registry unavailability** during the equivalent restart. The DB
retry-with-backoff in v1.7.1 covers most of it, but registry pods may
bounce once before they reconnect (one staging pod hit `Failed to
connect after 8 attempts` then recovered on its next restart).
**Time the merge for a low-traffic UTC window** — the alert history
suggests very early UTC is quietest.
## Post-merge action
Once the prod Pulumi run completes, run once on the existing cluster:
```bash
PATH=/opt/homebrew/share/google-cloud-sdk/bin:$PATH
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements"
```
Verify:
```bash
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -d app -c "
SELECT round(mean_exec_time::numeric, 2) AS mean_ms, calls,
substring(query, 1, 80) AS q
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;"
```
## Test plan
- [x] v1.7.2 release built and pushed
(`ghcr.io/modelcontextprotocol/registry:1.7.2`)
- [x] Staging deployed cleanly; `pg_stat_statements` is collecting on
staging
- [ ] Prod Pulumi run applies cleanly; brief PG restart
- [ ] Run `CREATE EXTENSION` on prod
- [ ] Confirm `publish complete` events contain per-phase timings on the
next publish
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Three changes from the 2026-04-27 incident:
1. **Cursor SQL fix** — `addCursorCondition` rewritten to use a
row-constructor comparison `(server_name, version) > ($1, $2)` instead
of the OR-decomposed form. Postgres can index-seek on the row
constructor; it can't on the OR form, which scanned from the start of
the index and filtered rows before the cursor. Cost grew linearly with
cursor depth.
2. **Per-phase publish timings restored** — `createServerInTransaction`
was simplified during #1211 review to log only `validate_ms`. The
incident showed publishes spending 50+ s in `acquire_lock` /
`version_checks` / `db_create` while `validate_ms` reported a few
hundred ms — the diagnostic signal was hidden. Restored timings for
every phase, refactored into a small `runPhase` helper.
3. **`pg_stat_statements` enabled** in the CNPG cluster spec. We had no
aggregate query visibility during the incident — could only EXPLAIN
queries we happened to suspect.
## Cursor fix evidence
Local benchmark, 100K rows, cold cache:
| Form | Rows filtered | Buffer reads | Time |
|------|--------------:|-------------:|-----:|
| OLD | 80,001 | 7,679 | 31.6 ms |
| NEW | 2 | 1 | **0.05 ms** |
Maps to prod's measured 8,911 buffer hits → 760 ms. End-to-end API:
`/v0/servers?limit=100&cursor=…` returns in 4–7 ms regardless of depth.
Risk check: confirmed `(server_name, version)` index exists in that
column order (both `servers_pkey` and `idx_servers_name_version`), and
both columns are `NOT NULL` so row-constructor comparison can't silently
drop rows.
## Tests
- New
`TestPostgreSQL_PerformanceScenarios/compound_cursor_across_versions_of_same_server`
pins multi-version pagination semantics. The existing cursor tests only
exercised the fallback (single-component cursor) and degenerate (one
version per server) cases.
- `make lint` clean, `go test -race ./internal/... ./cmd/...` green.
## Deployment
The cursor + slog changes are zero-downtime. The CNPG spec change
triggers a brief PG restart (single-instance cluster). After the
restart, run once on prod:
```bash
kubectl exec -i registry-pg-1 -c postgres \
--context gke_mcp-registry-prod_us-central1-b_mcp-registry-prod \
-- psql -U postgres -c "CREATE EXTENSION IF NOT EXISTS pg_stat_statements"
```
Time the merge for a low-traffic UTC window. v1.7.1's DB
retry-with-backoff covers the brief PG restart.
## Out of scope
`MaxConns` bump, per-IP rate limiting at nginx, response caching, the
pre-existing `superfluous WriteHeader` warnings — separate follow-ups.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Promotes
[v1.7.1](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.1)
to production. Contents: the hardening + diagnostics from #1211.
What's in v1.7.1 (vs v1.7.0):
- Pulumi-managed IAM bindings for the default compute SA so
fluentbit-gke and the GMP collector can ship logs/metrics (already
applied to live cluster manually)
- `PodDisruptionBudget` with `minAvailable: 1` +
`TopologySpreadConstraints` to keep pods spread across nodes
- `StartupProbe` (30 × 5s) covering the new DB-retry budget
- Bounded retry-with-backoff on initial DB connect in
`cmd/registry/main.go`
- Memory request 128→256Mi, limit 256→512Mi
- `slog` `validate_ms` timing on the publish path so the next slow
`/v0/publish` is self-diagnostic
## Test plan
- [x] v1.7.1 release workflow built and pushed image successfully
(`ghcr.io/modelcontextprotocol/registry:1.7.1`)
- [x] Pulumi.gcpProd.yaml diff is the single-line image bump
- [ ] On merge, `deploy-production.yml` rolls out v1.7.1 — watch for
clean rolling update (`maxSurge: 1`, `maxUnavailable: 0`) and confirm
both pods reach Ready
- [ ] After rollout, confirm `Starting MCP Registry Application v1.7.1`
shows up in Cloud Logging from the new pods
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Follow-up to #1211 to encode the GCP API and IAM dependencies its
node-SA bindings rely on. After #1211 merged, the staging deploy hit two
undocumented prereqs in sequence — Cloud Resource Manager API not
enabled (because `projects.NewIAMMember` calls SetIamPolicy through
CRM), then the Pulumi service account missing
`roles/resourcemanager.projectIamAdmin`. Both fixed manually to unblock;
this PR makes them explicit so they don't bite again.
## Changes
**`ensureRequiredAPIs` adopts five GCP APIs** as Pulumi-managed
`projects.Service` resources, all with `DisableOnDestroy: false` and
`DisableDependentServices: false` so a Pulumi destroy/refactor can never
disable a shared API:
| API | Why |
|-----|-----|
| `cloudresourcemanager` | `projects.NewIAMMember` → SetIamPolicy |
| `compute` | `compute.GetDefaultServiceAccount` invoke + GKE |
| `container` | GKE cluster |
| `logging` | fluentbit-gke ships container logs |
| `monitoring` | managed Prometheus collector ships metrics |
CRM is created explicitly (not in the loop) so callers get a direct
reference for `pulumi.DependsOn`. Storage is intentionally **not**
Pulumi-managed — Pulumi state itself lives in a GCS bucket,
chicken-and-egg.
**`grantNodeServiceAccountRoles`** now `DependsOn` the CRM
`projects.Service` for the four IAM bindings, and uses
`compute.GetDefaultServiceAccount` to derive the SA email (Compute API
was already required for GKE — avoids a CRM-dependent project-number
lookup).
**`deploy/README.md`** — adds `roles/resourcemanager.projectIamAdmin` to
the Pulumi SA's required roles and clarifies which APIs must be enabled
before the first `pulumi up` (storage, cloudresourcemanager, container)
vs. which `ensureRequiredAPIs` adopts.
## Notes
`projects.Service` is idempotent against already-enabled APIs — on
existing projects (staging/prod), Pulumi adopts the live enablement into
state without re-enabling. This was confirmed live: staging deploy went
green after the manual unblocks above, validating the runtime model.
## Test plan
- [x] `go build ./...` clean for `deploy/`
- [x] `golangci-lint run` clean for `deploy/pkg/providers/gcp/...` (one
pre-existing `nilnil` at line 61, unrelated)
- [x] Manual unblock + green staging deploy verified the runtime
behavior this PR encodes
- [ ] On merge: staging deploy adopts the existing API enablements
without churn, then proceeds normally
- [ ] Prod deploy via #1212 (image promotion) inherits the same setup
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Daily ~17:00 UTC `Publish Endpoint Latency` and `Availability < 95%`
alerts are caused by both registry pods exit-0'ing within seconds of
each other and racing with the still-recovering `registry-pg-rw`
endpoint on restart. Separately, the default compute SA had no project
IAM roles, so `fluentbit-gke` and the GMP collector were silently
dropping every log line and time series — which is why none of this was
visible in Cloud Logging.
All Kubernetes/IAM changes apply uniformly to staging and prod.
## Changes
- **GCP IAM** (`deploy/pkg/providers/gcp/provider.go`) — grant the
default compute SA `logging.logWriter`, `monitoring.metricWriter`,
`monitoring.viewer`, and `stackdriver.resourceMetadata.writer`. Already
applied live; this just encodes it in Pulumi.
- **Pod resilience** (`deploy/pkg/k8s/registry.go`) —
- `PodDisruptionBudget` (`minAvailable: 1`) prevents a synchronized
voluntary disruption.
- `TopologySpreadConstraints` (`ScheduleAnyway`, hostname) keeps the PDB
from deadlocking node drains when both pods co-locate.
- `StartupProbe` (30 × 5s = 150s) protects the DB-retry budget from the
liveness probe.
- Memory bump 128→256Mi request, 256→512Mi limit.
- **Startup retry** (`cmd/registry/main.go`) — replace silent `return`
on initial DB-ping failure with bounded retry-with-backoff (8 attempts,
1→8s capped, 10s per-attempt). A brief endpoint flap no longer cascades
into a restart loop.
- **Diagnostic log** (`internal/service/registry_service.go`) — emit
`validate_ms` on each publish (success and failure). Validate fans out
to npm/PyPI/OCI with 10s per-host timeouts and is the most likely
contributor to publish latency. Total request duration is already
covered by the existing `http.request.duration` histogram.
## Calibration
The IAM, PDB, topology-spread, startup-probe, and DB-retry pieces are
mitigations — they reduce blast radius regardless of root cause. The
`validate_ms` log is the diagnostic for identifying the trigger when the
alert fires next. Single-PG SPOF (`deploy/pkg/k8s/postgres.go:57`)
remains a follow-up; today's evidence shows PG was a victim, not the
cause.
## Test plan
- [x] `go build ./...` and `go vet ./...` clean for both modules
- [x] `make lint` clean (12 pre-existing issues under `deploy/` are not
in `make lint`)
- [x] `go test -race -count=1 ./internal/... ./cmd/...` green
- [x] IAM applied live; `fluentbit-gke` and GMP no longer hitting
`IAM_PERMISSION_DENIED`
- [ ] After deploy, verify the next 17:00 UTC firing surfaces
`validate_ms` in Cloud Logging
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
- Bumps production image tag from `1.6.0` to `1.7.0` in
`deploy/Pulumi.gcpProd.yaml`
- Corresponds to the [v1.7.0
release](https://github.com/modelcontextprotocol/registry/releases/tag/v1.7.0)
- Notable change: includes #1201 — fixes#1081 (`isLatest` no longer
stranded after soft-delete) and ships migration `014_heal_is_latest`
that auto-heals affected servers (e.g.
`io.github.containers/kubernetes-mcp-server`) on deploy
## Test plan
- [ ] Verify Pulumi preview shows only the image tag change
- [ ] After deploy, confirm migration 014 ran and
`io.github.containers/kubernetes-mcp-server`'s `/versions/latest`
returns `0.0.61` (or whichever is highest non-deleted)
- [ ] Sample a few unaffected servers and confirm `isLatest` is
unchanged
- [ ] Confirm overall service health
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Fixes#1081. When the version flagged `is_latest` was soft-deleted, no
other version was promoted, and because `GetCurrentLatestVersion` didn't
filter deleted rows, subsequent publishes with a lower semver never
became latest — leaving `/v0/servers/{name}/versions/latest` permanently
404.
This PR has two parts:
### 1. Code fix — recalculate `is_latest` on every status change
- Recalculate `is_latest` after every status mutation
(`UpdateServerStatus`, `UpdateAllVersionsStatus`, and the inline status
change in `UpdateServer`), in the same transaction that already holds
the per-server advisory lock.
- Winner selection reuses the existing `CompareVersions` logic: highest
non-deleted version gets the flag; if every version is deleted, the
highest deleted version keeps it so admin lookups via
`includeDeleted=true` still resolve the server (important for restore
flows).
- New `SetLatestVersion` DB primitive issues two statements (clear old,
set new) — `idx_unique_latest_per_server` is a non-deferrable unique
partial index, so a single `UPDATE` that flips two rows trips the
constraint.
### 2. One-shot migration — heal servers already affected (no manual SQL
needed)
`014_heal_is_latest.sql` promotes the highest non-deleted version on
every server whose `is_latest` flag is on a deleted row (or absent
entirely). Picker parses `major.minor.patch` numerically and falls back
to `published_at` for non-semver or as a tiebreaker. Heals
`io.github.containers/kubernetes-mcp-server` to `0.0.61` automatically
and catches any other servers silently affected by the original bug,
without hardcoded version numbers.
Picker behavior vs. `CompareVersions`:
- Standard `M.m.p` semver: matches exactly, including the
backport-after-delete case (e.g. published 1.0.1 then 1.0.0 hotfix after
deleting 2.0.0 → picks 1.0.1, not 1.0.0).
- Non-semver: falls through to `published_at DESC`. Reasonable.
- Prereleases (`1.0.0-alpha` vs `1.0.0`): both parse to `(1,0,0)`,
tiebreak by `published_at`. Diverges from `CompareVersions` (which
always says `1.0.0 > 1.0.0-alpha`). Edge case requires (a) server hit by
this bug AND (b) prereleases at the top of the version list. Acceptable;
the publisher can flip it with one `mcp-publisher status` call (which
now triggers proper recalc thanks to part 1).
## Verification
End-to-end curl repro of the exact scenario from the issue, run against
both `main` and this branch:
**Before (main):**
```
publish 1.0.0 → 200
publish 0.0.59 → 200
PATCH .../1.0.0/status {deleted} → 200
GET /versions/latest → 404 ← bug
publish 0.0.60 → 200
GET /versions/latest → 404 ← bug persists, 0.0.60 has isLatest=False
```
**After (this branch):**
```
publish 1.0.0 → 200
publish 0.0.59 → 200
PATCH .../1.0.0/status {deleted} → 200
GET /versions/latest → 200 (0.0.59, isLatest=true)
publish 0.0.60 → 200
GET /versions/latest → 200 (0.0.60, isLatest=true)
```
## Test plan
- [x] Service tests covering: soft-delete latest → next highest active
promoted; the exact #1081 repro end-to-end through the service;
all-versions-deleted still keeps highest addressable for admin;
restore-to-higher-version reclaims latest.
- [x] Migration tests covering: kubernetes-mcp-server scenario (heals to
highest semver); backport scenario (semver beats most-recent-published);
no-is_latest-row defensive case; all-deleted server left untouched;
healthy server left untouched; non-semver versions fall back to
`published_at`.
- [x] Full unit test suite (`./internal/... ./cmd/...`) passes against a
real Postgres.
- [x] `make lint` (0 issues) and `make validate` pass.
- [x] Manual curl repro against a running registry confirms the fix
resolves the failure mode and `main` still reproduces it.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
DNS auth users have repeatedly hit two failure modes that both produce
the same opaque "Ed25519 signature verification failed" error, making
them indistinguishable to debug. This PR makes both diagnosable
end-to-end without changing the auth protocol or any successful path.
The two recurring failure modes:
1. **Wrong placement** — TXT record put under a selector
(`_mcp-auth.<domain>` or `_mcp-registry.<domain>`) instead of the apex.
DKIM-style intuition, but MCP DNS auth uses SPF-style apex placement.
See #385 (PR #388 fixed the docs but the failure recurred), #1103,
#1126.
2. **Stale apex record** — old TXT record left behind after a key
rotation, silently tried first and rejected.
## Changes
**`internal/api/handlers/v0/auth/dns.go`** — when the apex has no
`v=MCPv1` record, probe `_mcp-auth.<domain>` and
`_mcp-registry.<domain>` in parallel (2s individual timeout). If a
record is found there, return a targeted error pointing the user at the
apex. Costs zero extra DNS work in the success path.
**`internal/api/handlers/v0/auth/common.go`** — when verification fails
against records that *are* present, include short fingerprints of every
key the registry tried (`ed25519:YJLsHFhu`-style 8-char prefix). A new
`ErrSignatureMismatch` sentinel keeps structural errors (wrong signature
size, unsupported algorithm) passing through unchanged via `errors.Is`,
so existing assertions on those messages still hold.
**`docs/modelcontextprotocol-io/authentication.mdx`** — anti-pattern
`<Warning>` callout in the DNS section explicitly warning against
selector placement and stale records.
**Tests** — two new tests:
- `TestDNSAuthHandler_WrongSelectorProbe` — verifies the probe surfaces
records found at `_mcp-auth.` / `_mcp-registry.` and falls through to
the standard error when nothing is found anywhere
- `TestDNSAuthHandler_StaleKeyFingerprintInError` — verifies the
fingerprint hint appears in the failure message for #1126's exact
scenario
One existing test assertion was updated from a generic `"signature
verification failed"` substring to the more specific `"invalid signature
size for ECDSA P-384"` it should always have been asserting; the new
sentinel-based logic surfaces structural errors verbatim.
## Test plan
- [x] `make lint` — clean
- [x] `make test-unit` — all auth tests pass (existing + 2 new)
- [x] Verified existing single-key and multi-key paths preserve their
original (more specific) error messages where they were already specific
- [ ] Reviewer to sanity-check the docs callout renders well in the
Mintlify theme
## Out of scope
The publisher-side preflight DNS check (cross-link in #845) is
intentionally **not** in this PR — that belongs in the broader CLI UX
work tracked by #845.
Refs #845, #385, #1103Fixes#1126
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
- Adds a short "Recommended: Namespaced Subkeys" subsection to
`official-registry-requirements.md`, documenting the reverse-DNS subkey
convention for `publisher-provided` metadata with one worked example
- Explicitly notes this is not enforced, to avoid churning the ~15
existing flat-key examples elsewhere in the docs
Closes#477
## Test plan
- [ ] Render the file on GitHub and verify the new subsection appears
right after the `Publisher-Provided Metadata` size-limit note
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
- Clarifies in the README that the prebuilt Docker image does not bundle
PostgreSQL and needs an external instance reachable via
\`MCP_REGISTRY_DATABASE_URL\`
- Points readers to \`docker-compose.yml\` as a working multi-container
example
Closes#723
## Test plan
- [ ] Render the README on GitHub and verify the note appears in the
"Alternative: Running a pre-built Docker image" section
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
Follow-up to #1145. When `mcpName` is set in `package.json`, it should
be the server name used by `mcp-publisher init`. Two issues addressed:
### 1. `getNameFromPackageJSON` mangled `mcpName` through npm-name
transformation
`mcpName` values are already in MCP server name format (e.g.
`io.github.foo/bar`). The existing code ran them through the
`@scope/name → io.github.scope/name` transform and its
`io.github.<your-username>/*` fallback, producing a broken double-prefix
result.
Example with `"mcpName": "io.github.acme/weather"`:
- Before: `io.github.<your-username>/io.github.acme/weather` ❌
- After: `io.github.acme/weather` ✅
### 2. `detectServerName` consulted git before `mcpName`
Even with `mcpName` set in `package.json`, a github.com git remote (or a
`repository` field) silently won — the function returned
`io.github.<owner>/<repo>` and never looked at `mcpName`. Per the
[quickstart
docs](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx),
*"The value of `mcpName` will be your server's name in the MCP
Registry"*, so `mcpName` should take precedence.
## Changes
- `cmd/publisher/commands/init.go`:
- New `getMcpNameFromPackageJSON()` helper that returns `mcpName` or
`""`.
- `detectServerName` checks `mcpName` first, before git remote and the
`name`-based fallback.
- `getNameFromPackageJSON` simplified — the now-redundant `mcpName`
branch was removed; it only handles the npm `name` transformation.
- `cmd/publisher/commands/init_test.go` (new): 5 cases through the
public `InitCommand` API covering `mcpName` as-is, fallback to scoped
`name`, fallback to placeholder, version fallback, and `mcpName` winning
over a GitHub `repository` URL.
This completes the fix for #737.
## Test plan
- [x] `go test ./cmd/publisher/commands/` passes (5 new subtests)
- [x] `golangci-lint run ./cmd/publisher/commands/` clean
- [ ] Manual: `mcp-publisher init` in a git-tracked directory with
`package.json` containing `mcpName` produces a `server.json` whose
`name` matches `mcpName`, not the repo slug
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds support for the Quay.io container registry to the OCI validator.
This allows MCP servers hosted on Quay.io to be registered and validated
by the official registry.
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Quay.io is a major, trusted public OCI registry widely used by the
cloud-native and open-source communities. Currently, attempting to
publish a server using a Quay image results in an unsupported OCI
registry error. This change enables developers to use Quay.io as a
first-class hosting option for their MCP server images.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
- **Unit Tests:** Updated `internal/validators/registries/oci_test.go`
to transition Quay.io from a rejected test case to an allowed one.
- **Pattern Matching:** Verified that the allowlist correctly handles
both specific image identifiers and general pattern matching for the
`quay.io` host.
- **Local Validation:** Ran `make check` to ensure no regressions in the
existing OCI validation logic.
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
No. This is an additive change that expands the allowlist of supported
registries. Existing configurations are unaffected.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
The implementation follows the existing pattern for OCI registries:
1. Added a `RegistryURLQuay` constant to `pkg/model` for consistency.
2. Hardcoded `quay.io` into the `allowedOCIRegistries` map in the
validator to minimize architectural complexity.
3. Updated all relevant documentation files (`package-types.mdx`,
`generic-server-json.md`, and `official-registry-requirements.md`) to
ensure the source of truth is updated across the project.
4. Validation remains scoped to public images; no private registry
authentication was added for this host.
Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
Co-authored-by: Radoslav Dimitrov <radoslav@stacklok.com>
## Summary
Addresses two related enhancements to `mcp-publisher init`:
- **Copy `version` from `package.json`** (#736): When `package.json` is
present and contains a `version` field, it is now used for both the
top-level `version` and `packages[].version` in the generated
`server.json`. Falls back to `"1.0.0"` when unavailable. This aligns
with the recommended best practice of keeping server version in sync
with package version.
- **Prefer `mcpName` over `name`** (#737): The init command now checks
for `mcpName` in `package.json` first, falling back to `name` if
`mcpName` is not defined. This ensures the generated server name matches
the required `mcpName` property.
Closes#736Closes#737
## Changes
- `cmd/publisher/commands/init.go`:
- Added `getVersionFromPackageJSON()` helper to read version from
`package.json`
- Modified `InitCommand()` to use detected version with `"1.0.0"`
fallback
- Modified `getNameFromPackageJSON()` to prefer `mcpName` over `name`
## Test plan
- [x] `go build ./cmd/publisher/...` compiles without errors
- [x] `go test ./cmd/publisher/commands/...` passes all existing tests
- [ ] Manual: run `mcp-publisher init` in a directory with
`package.json` containing `version` and `mcpName` — verify both are
copied to `server.json`
- [ ] Manual: run `mcp-publisher init` in a directory with
`package.json` without `mcpName` — verify `name` is used as fallback
- [ ] Manual: run `mcp-publisher init` in a directory without
`package.json` — verify defaults (`"1.0.0"`, directory name) are used
## AI Disclosure
AI assistance (Claude) was used for initial code exploration and issue
research. The implementation was written and reviewed by the author.
Co-authored-by: Radoslav Dimitrov <radoslav@stacklok.com>
Bumps
[github.com/pulumi/pulumi/sdk/v3](https://github.com/pulumi/pulumi) from
3.231.0 to 3.232.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/pulumi/pulumi/releases">github.com/pulumi/pulumi/sdk/v3's
releases</a>.</em></p>
<blockquote>
<h2>v3.232.0</h2>
<h2>3.232.0 (2026-04-22)</h2>
<h3>Features</h3>
<ul>
<li>
<p>[cli] Add an experimental <code>pulumi neo</code> command that
creates a Pulumi Neo agent task in CLI
tool-execution mode and runs the local tool loop. Filesystem and shell
tool calls
issued by the agent run on the user's machine in their working
directory; the
interactive chat continues to happen in the Pulumi Console at the URL
the command
prints. Hidden behind PULUMI_EXPERIMENTAL.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22473">#22473</a></p>
</li>
<li>
<p>[cli] Add support for handling user approval requests in the
<code>pulumi neo</code> terminal UI.
When the agent requests confirmation for a sensitive action, the TUI
prompts the
user and forwards their response back to the Pulumi Console. Hidden
behind
PULUMI_EXPERIMENTAL.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22589">#22589</a></p>
</li>
<li>
<p>[cli] Add an interactive terminal UI for <code>pulumi neo</code>
built with bubbletea, rendering
agent messages, tool calls, and streaming output in the terminal
alongside the
Pulumi Console session. Hidden behind PULUMI_EXPERIMENTAL.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22570">#22570</a></p>
</li>
<li>
<p>[cli] Switch logging library from glog to slog.</p>
</li>
</ul>
<p>BREAKING: any <code>if logging.V(x) {</code> need to be changed to
<code>if logging.V(x).Enabled()</code></p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22548">#22548</a></p>
<ul>
<li>
<p>[cli] Add a plan-mode toggle to the <code>pulumi neo</code> TUI,
bound to Shift+Tab. When
plan mode is on, Neo explores and asks questions without writing files,
running <code>pulumi up</code>, or opening PRs, and surfaces an approved
plan via a
dedicated approval gate. The toggle must be set before the first message
(plan mode is task-level on the wire); approving the proposed plan exits
plan mode automatically.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22634">#22634</a></p>
</li>
<li>
<p>[cli] The <code>pulumi neo</code> TUI now drives its
"thinking" spinner off a single declarative
rule (the spinner stays on until a final event — final assistant
message, approval
request, cancellation, or error — lands), so the indicator no longer
flickers off
when the agent hands off tool calls to the CLI or when streaming text
arrives
between tools. Press <code>Esc</code> during a turn to ask the agent to
cancel; the label
switches to "Cancelling..." until the backend
acknowledges.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22637">#22637</a></p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/pulumi/pulumi/blob/master/CHANGELOG.md">github.com/pulumi/pulumi/sdk/v3's
changelog</a>.</em></p>
<blockquote>
<h2>3.232.0 (2026-04-22)</h2>
<h3>Features</h3>
<ul>
<li>
<p>[cli] Add an experimental <code>pulumi neo</code> command that
creates a Pulumi Neo agent task in CLI
tool-execution mode and runs the local tool loop. Filesystem and shell
tool calls
issued by the agent run on the user's machine in their working
directory; the
interactive chat continues to happen in the Pulumi Console at the URL
the command
prints. Hidden behind PULUMI_EXPERIMENTAL.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22473">#22473</a></p>
</li>
<li>
<p>[cli] Add support for handling user approval requests in the
<code>pulumi neo</code> terminal UI.
When the agent requests confirmation for a sensitive action, the TUI
prompts the
user and forwards their response back to the Pulumi Console. Hidden
behind
PULUMI_EXPERIMENTAL.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22589">#22589</a></p>
</li>
<li>
<p>[cli] Add an interactive terminal UI for <code>pulumi neo</code>
built with bubbletea, rendering
agent messages, tool calls, and streaming output in the terminal
alongside the
Pulumi Console session. Hidden behind PULUMI_EXPERIMENTAL.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22570">#22570</a></p>
</li>
<li>
<p>[cli] Switch logging library from glog to slog.</p>
</li>
</ul>
<p>BREAKING: any <code>if logging.V(x) {</code> need to be changed to
<code>if logging.V(x).Enabled()</code></p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22548">#22548</a></p>
<ul>
<li>
<p>[cli] Add a plan-mode toggle to the <code>pulumi neo</code> TUI,
bound to Shift+Tab. When
plan mode is on, Neo explores and asks questions without writing files,
running <code>pulumi up</code>, or opening PRs, and surfaces an approved
plan via a
dedicated approval gate. The toggle must be set before the first message
(plan mode is task-level on the wire); approving the proposed plan exits
plan mode automatically.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22634">#22634</a></p>
</li>
<li>
<p>[cli] The <code>pulumi neo</code> TUI now drives its
"thinking" spinner off a single declarative
rule (the spinner stays on until a final event — final assistant
message, approval
request, cancellation, or error — lands), so the indicator no longer
flickers off
when the agent hands off tool calls to the CLI or when streaming text
arrives
between tools. Press <code>Esc</code> during a turn to ask the agent to
cancel; the label
switches to "Cancelling..." until the backend
acknowledges.</p>
<p><a
href="https://redirect.github.com/pulumi/pulumi/pull/22637">#22637</a></p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="59d156aaea"><code>59d156a</code></a>
Add <code>l2-plain-component</code> & remove test dependencies on
AWS (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22470">#22470</a>)</li>
<li><a
href="3efae3eafd"><code>3efae3e</code></a>
Cancel providers before closing them (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22692">#22692</a>)</li>
<li><a
href="448770ec12"><code>448770e</code></a>
Add l2-id-type test (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22681">#22681</a>)</li>
<li><a
href="cc8a16f376"><code>cc8a16f</code></a>
go/auto: use random stack names in TestNestedConfig (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22689">#22689</a>)</li>
<li><a
href="6b5ce009ee"><code>6b5ce00</code></a>
skip signal cancellation tests (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22684">#22684</a>)</li>
<li><a
href="923073c621"><code>923073c</code></a>
fix[codegen/go]: Use Context.GetOrRegisterPackageRef in generated code
(<a
href="https://redirect.github.com/pulumi/pulumi/issues/22170">#22170</a>)</li>
<li><a
href="2608e2c071"><code>2608e2c</code></a>
Gitignore <code>.claude/scheduled_tasks.lock</code> (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22686">#22686</a>)</li>
<li><a
href="3e387c7355"><code>3e387c7</code></a>
chore: typo <code>succesful</code> -> <code>successful</code> in
nodejs run/index.ts (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22685">#22685</a>)</li>
<li><a
href="a850bcbfef"><code>a850bcb</code></a>
Update dependency pulumi/pulumi-java to v1.25.0 (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22673">#22673</a>)</li>
<li><a
href="416fd51b5f"><code>416fd51</code></a>
replace underlying logging library with slog (<a
href="https://redirect.github.com/pulumi/pulumi/issues/22548">#22548</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/pulumi/pulumi/compare/v3.231.0...v3.232.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## What
Two targeted additions to `docs/modelcontextprotocol-io/quickstart.mdx`:
1. A `<Note>` immediately after the tutorial's intro, telling PyPI /
NuGet / OCI / MCPB publishers that the Step 1 ownership-verification
mechanism differs for their package type and pointing them to [Package
Types](./package-types) before continuing.
2. The troubleshooting row for **"Registry validation failed for
package"** previously named only npm's `mcpName` property in
`package.json`. It now names all three current mechanisms (npm →
`mcpName` in `package.json`; PyPI / NuGet → `mcp-name: <server-name>`
line in the package README; other types → link to Package Types).
+5 / -1 lines.
## Why
The quickstart is the landing page for new publishers, but it's entirely
TypeScript / npm-flavored — the Step 1 example shows npm's `mcpName`
property and nothing else. The cross-reference to `./package-types` only
appears in the "Next Steps" footer, by which point a PyPI publisher has
already gone through every step and hit a `400 Bad Request` at
`mcp-publisher publish`:
> `registry validation failed for package 0 (<pkg>): PyPI package
'<pkg>' ownership validation failed. The server name
'io.github.<user>/<server>' must appear as 'mcp-name:
io.github.<user>/<server>' in the package README`
That specific error has tripped at least one other publisher (#531) and
was what motivated this change. The ownership mechanism is correctly
documented at `./package-types` — the fix is purely to route people
there before they publish, not to duplicate the content.
## What this change is **not**
- It does not propose changing the validation logic.
- It does not duplicate content from `package-types.mdx` into the
quickstart.
- It does not add a separate PyPI-specific tutorial. The existing
npm-flavored tutorial remains the canonical one; the note just tells
non-npm readers which step is different.
## Verification
- Change is docs-only; no build or test impact.
- Link target `./package-types` is the same shape as the one already
used in "Next Steps" of the same file.
- Anchor `#step-1-add-verification-information-to-the-package` matches
the existing heading's slug.
## Related
- #531 — same validation error hit by another PyPI publisher; closed
with a workaround but the quickstart wasn't updated.
Fixes#1169
Update the openapi.yml to add a missing field
## Motivation and Context
openapi.yml was not in sync with live data
## How Has This Been Tested?
Validated the openapi.yml file
## Breaking Changes
No
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Jeff MAURY <jmaury@redhat.com>
Co-authored-by: Radoslav Dimitrov <radoslav@stacklok.com>
Bumps [github.com/jackc/pgx/v5](https://github.com/jackc/pgx) from 5.9.1
to 5.9.2.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/jackc/pgx/blob/master/CHANGELOG.md">github.com/jackc/pgx/v5's
changelog</a>.</em></p>
<blockquote>
<h1>5.9.2 (April 18, 2026)</h1>
<p>Fix SQL Injection via placeholder confusion with dollar quoted string
literals (GHSA-j88v-2chj-qfwx)</p>
<p>SQL injection can occur when:</p>
<ol>
<li>The non-default simple protocol is used.</li>
<li>A dollar quoted string literal is used in the SQL query.</li>
<li>That query contains text that would be would be interpreted outside
as a placeholder outside of a string literal.</li>
<li>The value of that placeholder is controllable by the attacker.</li>
</ol>
<p>e.g.</p>
<pre lang="go"><code>attackValue := `$tag$; drop table canary; --`
_, err = tx.Exec(ctx, `select $tag$ $1 $tag$, $1`,
pgx.QueryExecModeSimpleProtocol, attackValue)
</code></pre>
<p>This is unlikely to occur outside of a contrived scenario.</p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0aeabbcf11"><code>0aeabbc</code></a>
Release v5.9.2</li>
<li><a
href="60644f8491"><code>60644f8</code></a>
Fix SQL sanitizer bugs with dollar-quoted strings and placeholder
overflow</li>
<li><a
href="a5680bc945"><code>a5680bc</code></a>
Merge pull request <a
href="https://redirect.github.com/jackc/pgx/issues/2531">#2531</a> from
dolmen-go/godoc-add-links</li>
<li><a
href="e34e452400"><code>e34e452</code></a>
doc: Add godoc links</li>
<li><a
href="08c9bb1f0d"><code>08c9bb1</code></a>
Fix Stringer types encoded as text instead of numeric value in composite
fields</li>
<li><a
href="96b4dbdfd0"><code>96b4dbd</code></a>
Remove unstable test</li>
<li><a
href="acf88e0065"><code>acf88e0</code></a>
Merge pull request <a
href="https://redirect.github.com/jackc/pgx/issues/2526">#2526</a> from
abrightwell/abrightwell-min-proto</li>
<li><a
href="2f81f1fc03"><code>2f81f1f</code></a>
Update <code>max_protocol_version</code> and
<code>min_protocol_version</code> defaults</li>
<li>See full diff in <a
href="https://github.com/jackc/pgx/compare/v5.9.1...v5.9.2">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
## Summary
- Bumps production image tag from `1.5.0` to `1.6.0` in
`deploy/Pulumi.gcpProd.yaml`
- Corresponds to the [v1.6.0
release](https://github.com/modelcontextprotocol/registry/releases/tag/v1.6.0)
## Test plan
- [ ] Verify Pulumi preview shows only the image tag change
- [ ] Deploy and confirm the service is healthy
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
When `detectRepoURL()` cannot determine the repository (no git remote,
no package.json repository field), return an empty string instead of a
placeholder URL (`https://github.com/YOUR_USERNAME/YOUR_REPO`). This
causes `createServerJSON()` to omit the `repository` field entirely,
preventing schema validation failures on publish.
Fixes#613
## Problem
`mcp-publisher init` generated a `repository` object with a placeholder
URL that fails the `uri` format validation on publish. 88 published
servers in the official registry had this issue.
## Change
- `cmd/publisher/commands/init.go`: `detectRepoURL()` returns `""`
instead of placeholder when no repo is found
- The existing guard in `createServerJSON()` (`if repoURL != "" &&
repoSource != ""`) already handles this correctly — it omits the
repository when URL is empty
## Test plan
- [x] `go build ./cmd/publisher/...` compiles
- [x] `go test ./cmd/publisher/commands/...` passes
- [ ] Manual: `mcp-publisher init` in a directory without git remote or
package.json repo — verify no `repository` field in generated
server.json
- [ ] Manual: `mcp-publisher init` in a git repo — verify `repository`
is populated correctly
## AI Disclosure
AI assistance (Claude) was used for issue research. The implementation
was written and reviewed by the author.
## Summary
Fixes#663
- **Security fix**: `mcp-publisher login` no longer writes
`.mcpregistry_github_token` and `.mcpregistry_registry_token` to the
current working directory. GitHub tokens are kept in memory during the
login→exchange flow and cleared immediately after.
- **Token location**: Unified token moved from `~/.mcp_publisher_token`
to `~/.config/mcp-publisher/token.json` (dir 0700, file 0600), following
the convention used by `gh`, `docker`, and `kubectl`.
- **Dead code removed**: `NeedsLogin()` was on the `Provider` interface
but never called — removed from interface and all 4 implementations.
`forceLogin` field also removed.
- **Auth tests added**: 11 new tests for `GitHubATProvider` (package
previously had 0 tests).
- **Test isolation**: `SetupTestToken` now uses `t.TempDir()` +
`t.Setenv("HOME", ...)` instead of writing to real `$HOME`.
### Breaking change
Users must re-login after upgrading (`mcp-publisher login <method>`).
Existing tokens at `~/.mcp_publisher_token` are not auto-migrated.
`logout` cleans up both old and new locations.
## Test plan
- [x] `make check` passes (lint, unit tests, integration tests)
- [x] `mcp-publisher login none` stores token at
`~/.config/mcp-publisher/token.json`
- [x] No `.mcpregistry_*` files created in cwd after login (with
`--token`, `MCP_GITHUB_TOKEN`, or device flow)
- [x] `mcp-publisher publish` reads token from new location
- [x] `mcp-publisher validate` reads registry URL from new location
- [x] `mcp-publisher logout` cleans up new location, legacy
`~/.mcp_publisher_token`, and cwd `.mcpregistry_*` files
- [x] `mcp-publisher logout` when not logged in shows "Not logged in"
- [x] File permissions: dir 0700, file 0600
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bumps [github.com/coreos/go-oidc/v3](https://github.com/coreos/go-oidc)
from 3.17.0 to 3.18.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/coreos/go-oidc/releases">github.com/coreos/go-oidc/v3's
releases</a>.</em></p>
<blockquote>
<h2>v3.18.0</h2>
<h2>What's Changed</h2>
<ul>
<li>.github: configure dependabot by <a
href="https://github.com/ericchiang"><code>@ericchiang</code></a> in <a
href="https://redirect.github.com/coreos/go-oidc/pull/477">coreos/go-oidc#477</a></li>
<li>.github: update go versions in CI by <a
href="https://github.com/ericchiang"><code>@ericchiang</code></a> in <a
href="https://redirect.github.com/coreos/go-oidc/pull/480">coreos/go-oidc#480</a></li>
<li>build(deps): bump golang.org/x/oauth2 from 0.28.0 to 0.36.0 by <a
href="https://github.com/dependabot"><code>@dependabot</code></a>[bot]
in <a
href="https://redirect.github.com/coreos/go-oidc/pull/478">coreos/go-oidc#478</a></li>
<li>build(deps): bump github.com/go-jose/go-jose/v4 from 4.1.3 to 4.1.4
by <a
href="https://github.com/dependabot"><code>@dependabot</code></a>[bot]
in <a
href="https://redirect.github.com/coreos/go-oidc/pull/479">coreos/go-oidc#479</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/coreos/go-oidc/compare/v3.17.0...v3.18.0">https://github.com/coreos/go-oidc/compare/v3.17.0...v3.18.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="da6b3bfca8"><code>da6b3bf</code></a>
build(deps): bump github.com/go-jose/go-jose/v4 from 4.1.3 to 4.1.4</li>
<li><a
href="7f80694215"><code>7f80694</code></a>
build(deps): bump golang.org/x/oauth2 from 0.28.0 to 0.36.0</li>
<li><a
href="7271de5758"><code>7271de5</code></a>
.github: update go versions in CI</li>
<li><a
href="3ccf20fdc4"><code>3ccf20f</code></a>
.github: configure dependabot</li>
<li>See full diff in <a
href="https://github.com/coreos/go-oidc/compare/v3.17.0...v3.18.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Radoslav Dimitrov <radoslav@stacklok.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
We keep bumping `go 1.26.x` across the repo every time a new Go patch
drops
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
- **`go.mod` / `deploy/go.mod`**: `go 1.25.8` → `go 1.26` (minor only —
"this module needs Go 1.26")
- **All CI workflows**: `go-version-file: 'go.mod'` → `go-version:
'stable'` — CI always uses the latest stable Go, no more
bump PRs
- **govulncheck**: removed hardcoded `go-version-input: '1.26.1'` →
`go-version-input: 'stable'`
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
Bumps [github.com/jackc/pgx/v5](https://github.com/jackc/pgx) from 5.8.0
to 5.9.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/jackc/pgx/blob/master/CHANGELOG.md">github.com/jackc/pgx/v5's
changelog</a>.</em></p>
<blockquote>
<h1>5.9.1 (March 22, 2026)</h1>
<ul>
<li>Fix: batch result format corruption when using cached prepared
statements (reported by Dirkjan Bussink)</li>
</ul>
<h1>5.9.0 (March 21, 2026)</h1>
<p>This release includes a number of new features such as
SCRAM-SHA-256-PLUS support, OAuth authentication support, and
PostgreSQL protocol 3.2 support.</p>
<p>It significantly reduces the amount of network traffic when using
prepared statements (which are used automatically by
default) by avoiding unnecessary Describe Portal messages. This also
reduces local memory usage.</p>
<p>It also includes multiple fixes for potential DoS due to panic or OOM
if connected to a malicious server that sends
deliberately malformed messages.</p>
<ul>
<li>Require Go 1.25+</li>
<li>Add SCRAM-SHA-256-PLUS support (Adam Brightwell)</li>
<li>Add OAuth authentication support for PostgreSQL 18 (David
Schneider)</li>
<li>Add PostgreSQL protocol 3.2 support (Dirkjan Bussink)</li>
<li>Add tsvector type support (Adam Brightwell)</li>
<li>Skip Describe Portal for cached prepared statements reducing network
round trips</li>
<li>Make LoadTypes query easier to support on "postgres-like"
servers (Jelte Fennema-Nio)</li>
<li>Default empty user to current OS user matching libpq behavior
(ShivangSrivastava)</li>
<li>Optimize LRU statement cache with custom linked list and node
pooling (Mathias Bogaert)</li>
<li>Optimize date scanning by replacing regex with manual parsing
(Mathias Bogaert)</li>
<li>Optimize pgio append/set functions with direct byte shifts (Mathias
Bogaert)</li>
<li>Make RowsAffected faster (Abhishek Chanda)</li>
<li>Fix: Pipeline.Close panic when server sends multiple FATAL errors
(Varun Chawla)</li>
<li>Fix: ContextWatcher goroutine leak (Hank Donnay)</li>
<li>Fix: stdlib discard connections with open transactions in
ResetSession (Jeremy Schneider)</li>
<li>Fix: pipelineBatchResults.Exec silently swallowing lastRows
error</li>
<li>Fix: ColumnTypeLength using BPCharArrayOID instead of BPCharOID</li>
<li>Fix: TSVector text encoding returning nil for valid empty
tsvector</li>
<li>Fix: wrong error messages for Int2 and Int4 underflow</li>
<li>Fix: Numeric nil Int pointer dereference with Valid: true</li>
<li>Fix: reversed strings.ContainsAny arguments in
Numeric.ScanScientific</li>
<li>Fix: message length parsing on 32-bit platforms</li>
<li>Fix: FunctionCallResponse.Decode mishandling of signed result
size</li>
<li>Fix: returning wrong error in configTLS when DecryptPEMBlock fails
(Maxim Motyshen)</li>
<li>Fix: misleading ParseConfig error when default_query_exec_mode is
invalid (Skarm)</li>
<li>Fix: missed Unwatch in Pipeline error paths</li>
<li>Clarify too many failed acquire attempts error message</li>
<li>Better error wrapping with context and SQL statement (Aneesh
Makala)</li>
<li>Enable govet and ineffassign linters (Federico Guerinoni)</li>
<li>Guard against various malformed binary messages (arrays, hstore,
multirange, protocol messages)</li>
<li>Fix various godoc comments (ferhat elmas)</li>
<li>Fix typos in comments (Oleksandr Redko)</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4e4eaedb47"><code>4e4eaed</code></a>
Release v5.9.1</li>
<li><a
href="6273188265"><code>6273188</code></a>
Fix batch result format corruption when using cached prepared
statements</li>
<li><a
href="f7b90c2f1a"><code>f7b90c2</code></a>
Merge pull request <a
href="https://redirect.github.com/jackc/pgx/issues/2524">#2524</a> from
dbussink/pipeline-result-format-reuse</li>
<li><a
href="3ce6d75be4"><code>3ce6d75</code></a>
Add failing test: batch scan corrupted in cache_statement mode</li>
<li><a
href="b4d8e62b66"><code>b4d8e62</code></a>
Release v5.9.0</li>
<li><a
href="c227cd4f76"><code>c227cd4</code></a>
Bump minimum Go version from 1.24 to 1.25</li>
<li><a
href="f492c14836"><code>f492c14</code></a>
Use reflect.TypeFor instead of reflect.TypeOf for static types</li>
<li><a
href="ad8fb08d3f"><code>ad8fb08</code></a>
Use sync.WaitGroup.Go to simplify goroutine spawning</li>
<li><a
href="303377376d"><code>3033773</code></a>
Remove go1.26 build tag from synctest test</li>
<li><a
href="83ffb3c222"><code>83ffb3c</code></a>
Validate multirange element count against source length before
allocating</li>
<li>Additional commits viewable in <a
href="https://github.com/jackc/pgx/compare/v5.8.0...v5.9.1">compare
view</a></li>
</ul>
</details>
<br />
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps the actions group with 2 updates in the / directory:
[actions/setup-go](https://github.com/actions/setup-go) and
[sigstore/cosign-installer](https://github.com/sigstore/cosign-installer).
Updates `actions/setup-go` from 6.3.0 to 6.4.0
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/actions/setup-go/releases">actions/setup-go's
releases</a>.</em></p>
<blockquote>
<h2>v6.4.0</h2>
<h2>What's Changed</h2>
<h3>Enhancement</h3>
<ul>
<li>Add go-download-base-url input for custom Go distributions by <a
href="https://github.com/gdams"><code>@gdams</code></a> in <a
href="https://redirect.github.com/actions/setup-go/pull/721">actions/setup-go#721</a></li>
</ul>
<h3>Dependency update</h3>
<ul>
<li>Upgrade minimatch from 3.1.2 to 3.1.5 by <a
href="https://github.com/dependabot"><code>@dependabot</code></a> in <a
href="https://redirect.github.com/actions/setup-go/pull/727">actions/setup-go#727</a></li>
</ul>
<h3>Documentation update</h3>
<ul>
<li>Rearrange README.md, add advanced-usage.md by <a
href="https://github.com/priyagupta108"><code>@priyagupta108</code></a>
in <a
href="https://redirect.github.com/actions/setup-go/pull/724">actions/setup-go#724</a></li>
<li>Fix Microsoft build of Go link by <a
href="https://github.com/gdams"><code>@gdams</code></a> in <a
href="https://redirect.github.com/actions/setup-go/pull/734">actions/setup-go#734</a></li>
</ul>
<h2>New Contributors</h2>
<ul>
<li><a href="https://github.com/gdams"><code>@gdams</code></a> made
their first contribution in <a
href="https://redirect.github.com/actions/setup-go/pull/721">actions/setup-go#721</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/actions/setup-go/compare/v6...v6.4.0">https://github.com/actions/setup-go/compare/v6...v6.4.0</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4a3601121d"><code>4a36011</code></a>
docs: fix Microsoft build of Go link (<a
href="https://redirect.github.com/actions/setup-go/issues/734">#734</a>)</li>
<li><a
href="8f19afcc70"><code>8f19afc</code></a>
feat: add go-download-base-url input for custom Go distributions (<a
href="https://redirect.github.com/actions/setup-go/issues/721">#721</a>)</li>
<li><a
href="27fdb267c1"><code>27fdb26</code></a>
Bump minimatch from 3.1.2 to 3.1.5 (<a
href="https://redirect.github.com/actions/setup-go/issues/727">#727</a>)</li>
<li><a
href="def8c394e3"><code>def8c39</code></a>
Rearrange README.md, add advanced-usage.md (<a
href="https://redirect.github.com/actions/setup-go/issues/724">#724</a>)</li>
<li>See full diff in <a
href="4b73464bb3...4a3601121d">compare
view</a></li>
</ul>
</details>
<br />
Updates `sigstore/cosign-installer` from 4.1.0 to 4.1.1
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/sigstore/cosign-installer/releases">sigstore/cosign-installer's
releases</a>.</em></p>
<blockquote>
<h2>v4.1.1</h2>
<h2>What's Changed</h2>
<ul>
<li>chore: update default cosign-release to v3.0.5 in <a
href="https://redirect.github.com/sigstore/cosign-installer/pull/223">sigstore/cosign-installer#223</a></li>
</ul>
<p><strong>Full Changelog</strong>: <a
href="https://github.com/sigstore/cosign-installer/compare/v4.1.0...v4.1.1">https://github.com/sigstore/cosign-installer/compare/v4.1.0...v4.1.1</a></p>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="cad07c2e89"><code>cad07c2</code></a>
chore: update default cosign-release to v3.0.5 (<a
href="https://redirect.github.com/sigstore/cosign-installer/issues/223">#223</a>)</li>
<li>See full diff in <a
href="ba7bc0a3fe...cad07c2e89">compare
view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Radoslav Dimitrov
dependabot[bot]
Mikel Olasagasti Uranga
Yusufhan Saçak
Ashwanthram K L
Jeff MAURY