database-migrations

4 posts

gitlab

GitLab Patch Release: 18.8.11 | GitLab Docs (opens in new tab)

GitLab 18.8.11 is an out-of-band patch release for Community and Enterprise Editions, released July 1, 2026. It fixes a regression introduced by the Rails 7.2 upgrade that could cause database connections to leak when database load balancing is enabled. The release contains no security fixes or new migrations. ## Database Connection Leak Fix - Resolves database connection leaks affecting installations that use database load balancing. - Intended to improve stability for customers upgrading to the required GitLab 18.8 stop. ## Upgrade Considerations - No new database migrations are included. - Multi-node deployments should not require downtime. - Omnibus packages normally stop GitLab, run migrations, and restart during upgrades, regardless of upgrade size. - Administrators can disable this automatic reconfiguration for upgrades by creating: ```text /etc/gitlab/skip-auto-reconfigure ``` ## Updating and Subscriptions - Administrators should follow GitLab’s update instructions to install 18.8.11. - Premium and Ultimate features require a paid subscription, while GitLab.com provides access to GitLab-hosted infrastructure. Upgrade to 18.8.11 particularly if database load balancing is enabled, as it addresses a stability-related connection leak without introducing migration or downtime requirements.

cloudflare

Unlocking the Cloudflare app ecosystem with OAuth for all (opens in new tab)

Cloudflare opened self-managed OAuth to all customers so developers can build SaaS integrations, internal platforms, CI/CD workflows, and agentic tools without relying on difficult-to-manage API tokens. The expansion required improvements to permissions, consent, revocation, and phishing protections, as well as a major upgrade to the Hydra-based OAuth engine. Cloudflare used staged migrations, custom database changes, token-handling safeguards, and queued revocations to minimize disruption and preserve users’ security controls. ## Why Cloudflare Expanded OAuth Access - Previously, third-party OAuth integrations were limited to manually approved partners. - Other developers had to use API tokens, which are less convenient and poorly suited to delegated access. - Self-managed OAuth lets customers: - Request narrowly scoped permissions. - Give users clearer consent controls. - Revoke application access from the dashboard. - Build integrations and agentic tools using standard OAuth flows. - Cloudflare improved consent screens to identify the requesting application and its permissions, while making application ownership more visible to reduce phishing risks. ## Planning the Hydra Upgrade - Cloudflare used Hydra, an open-source OAuth engine, but its older deployment could not support the platform’s growing scale and new use cases. - The upgrade was split into two stages: - First, move to the latest 1.X release. - Then, perform the larger 2.X migration. - The 1.X database migrations created operational risks: - Standard index creation could take exclusive locks on critical tables. - Schema changes added columns and moved data between tables. - Hydra’s SDK used `SELECT *`, creating deserialization problems after schema changes. - Cloudflare rewrote migrations to use `CREATE INDEX CONCURRENTLY` and built a custom Hydra version that selected explicit columns. ## Designing a Blue-Green Migration - An in-place 2.X upgrade was rejected because of the volume of schema changes. - A blue-green deployment was chosen, but the migration would take several hours. - Disabling writes would prevent new authorizations and revocations, leaving users unable to manage application access during the upgrade. - Instead, Cloudflare kept writes enabled while reducing the amount of data that could be lost during the cutover: - Token expiry times were temporarily extended to multiple hours, reducing refresh-token writes. - Revocation events were written to Cloudflare Queues. - After switching to the green database, queued revocations could be replayed. - Preserving revocations was essential to prevent applications that users had disabled from regaining access. ## Lessons from the 1.X Upgrade - The custom migrations completed faster than expected without user impact. - A hard cutover was necessary because the old Hydra version could not read tokens created by the new version. - The new version introduced stricter refresh-token invalidation: - Reusing a refresh token invalidated the entire access and refresh-token chain. - This caused problems for high-volume clients such as Wrangler and MCP clients. - Cloudflare added refresh-token coalescing in the Worker routing layer: - Briefly caching requests allowed retries to be served without triggering invalidation. - Hydra 2.X provides a configurable refresh-token grace period, offering a more direct solution for safe retries. ## Executing the 2.X Upgrade - Cloudflare prepared a blue-green migration to avoid several hours of customer-facing downtime. - The strategy depended on reducing token writes, recording all revocations externally, switching databases, and replaying queued events afterward. - The provided article ends while beginning the detailed discussion of the 2.X execution. Cloudflare’s approach demonstrates that opening a security-sensitive platform to broad OAuth usage requires more than exposing an authorization endpoint. Safe adoption depends on explicit permissions, transparent consent, reliable revocation, backward-compatible token behavior, and migration plans that protect users even during infrastructure cutovers.

gitlab

GitLab Patch Release: 18.11.2, 18.10.5 | GitLab Docs (opens in new tab)

GitLab released patch versions 18.11.2 and 18.10.5 on April 29, 2026, for Community and Enterprise Editions. The releases address an observability gap affecting disaster recovery RTO/RPO commitments for GitLab Dedicated and fix several regressions and bugs. No security fixes are included. ## Changes in GitLab 18.11.2 - Reverts the `ia-refactor-role-permission-enablement` merge. - Adds Code Suggestions to DAP-supported features for self-hosted models. - Preserves DAP code review access for Duo Core users. - Clears persisted filters when loading the `/work_items` page. - Adds a GraphQL mutation for retrying failed reassignment operations. - Resolves Sidekiq spikes when users are banned. - Fixes MCP OAuth discovery for installations using relative URLs. - Adds the `*_oldest_unsynced_time` metric. - Includes additional changes related to disaster recovery observability. ## Changes in GitLab 18.10.5 - Adds Code Suggestions support for self-hosted models through DAP. - Updates the Duo CLI version used for remote flows. - Skips three migrations that reference dropped tables. - Preserves DAP code review access for Duo Core users. - Resolves Sidekiq spikes caused when users are banned. - Fixes missing `model_definitions` in self-hosted feature settings. - Prevents `CreateOrUpdateDefaultTrackedContextWorker` from running on Geo secondaries. - Adds the `*_oldest_unsynced_time` metric. ## Upgrade and migration impact - **Single-node installations:** Expect downtime because migrations must finish before GitLab starts. - **Multi-node installations:** Zero-downtime procedures can allow upgrades without downtime. - **Regular migrations:** Included in version 18.10.5. - **Post-deploy migrations:** Included in both 18.11.2 and 18.10.5. Administrators should follow GitLab’s standard upgrade guidance for single-node systems and zero-downtime procedures for multi-node deployments before updating.

stripe

Can AI agents build real Stripe integrations? We built a benchmark to find out (opens in new tab)

State-of-the-art LLM agents can complete many scoped coding tasks, but fully autonomous software engineering remains difficult because real projects require long-term planning, persistent state, debugging, and end-to-end validation. Stripe evaluated this gap through a benchmark of realistic backend, frontend, database, and browser-based integration tasks. The results were stronger than expected: agents demonstrated substantial full-stack capability, but still struggled with ambiguity and the judgment required to distinguish genuine failures from bad test inputs. ## Building the Stripe Integration Benchmark - Stripe created 11 environments based on real integration challenges, including Checkout migrations and Billing API modeling. - Each environment included: - A complete codebase, database, scripts, and test Stripe credentials. - Deterministic graders using API calls, automated browser tests, or inspection of Stripe objects. - A consistent agent harness with terminal, browser, and Stripe-specific search tools through MCP. - Challenges were divided into: - **Backend-only tasks:** SDK upgrades, API changes, and database migrations. - **Full-stack tasks:** Coordinated server and client changes requiring browser verification. - **Gym problem sets:** Focused exercises testing deep knowledge of features such as Checkout and subscriptions. ## Stronger-than-Expected Agent Performance - The benchmark intentionally used fewer, harder tasks designed to expose weaknesses. - Agents successfully: - Navigated browser interfaces. - Debugged live issues. - Worked with underdocumented API behavior. - Continued productively across long interactions, with top runs averaging 63 turns. - Claude Opus 4.5 achieved a 92% average score across four full-stack tasks. - GPT-5.2 achieved a 73% average score across two gym problem sets. - In a migration from Card Element to Checkout, an agent completed and verified a test purchase using Link, despite no payment method being specified. ## Reverse-Engineering Checkout Configurations - A Checkout gym task required agents to infer API parameters from 20 prebuilt Checkout UIs. - Agents had to: - Inspect products and quantities shown in each session. - Locate matching product IDs through the Products API. - Identify shipping costs, custom fields, tax settings, and other customizations. - Translate those details into valid Checkout Session parameters. - Agents provided more than 80% of the correct parameters. - The best-performing agent recognized that one UI’s color options were hidden behind an interactive dropdown, explored the control, and included the missing values. ## Remaining Challenges with Ambiguity - Agents struggled when evaluation situations required judgment rather than straightforward implementation. - In SDK upgrade tasks, some agents supplied nonexistent Stripe data, received expected 400 errors, and treated those responses as evidence that their implementation was broken. - This illustrates a broader limitation: successful autonomous engineering requires not only writing code, but also designing meaningful tests, interpreting failures correctly, and validating behavior against realistic system state. The benchmark suggests that agents are increasingly capable of substantial Stripe integration work, including full-stack implementation and browser-based verification. However, reliable autonomy will require better handling of ambiguity, realistic test data, persistent project state, and rigorous end-to-end validation.