Faith & Code | Reflections by Errong

GitHub Actions Is Blocking pull_request_target by Default: What to Change Before December 2 GitHub is changing the default security posture of GitHub Actions in public repositories. Starting December 2, 2026 , GitHub will block pull_request_target events by default unless an applicable Actions event policy explicitly allows them. Before enforcement, GitHub is using evaluate mode and scheduled brownouts to expose workflows that will be affected. This is more than a settings change. pull_request_target runs with the base repository's workflow, token, and potentially its secrets. That privilege is useful for trusted automation such as labeling or triage, but it becomes dangerous when the workflow checks out and executes code supplied by an untrusted pull request. Why this trigger is different A normal pull_request workflow is designed to process fork contributions with reduced privileges: GitHub uses the pull request's merge commit, gives the job a read-only token by default...

PostgreSQL 18 Async I/O: Measure It Before You Tune It PostgreSQL 18 adds a substantial change beneath familiar SQL: an asynchronous I/O subsystem. Instead of making every eligible read wait for completion before requesting the next one, PostgreSQL can keep multiple storage requests in flight. The project reports up to 3x improvement in some storage-read scenarios. That headline is useful, but it is not a tuning promise. The benefit depends on the operations your workload performs, the latency and throughput of its storage, the amount of concurrency, and the PostgreSQL build and operating system. The right lesson is not “turn on io_uring .” It is “benchmark the I/O path that your workload actually uses.” What changed in PostgreSQL 18 PostgreSQL 18 can use asynchronous I/O for operations including sequential scans, bitmap heap scans, and vacuum. The new io_method setting selects how asynchronous-eligible I/O is executed: worker uses PostgreSQL worker processes and is the default....

PostgreSQL 18 UUIDv7: A Better Default for New IDs? UUIDs are useful when identifiers need to be created independently, but UUIDv4 values are random. When a UUID is the primary key of a B-tree index, inserting random values can send writes to many different parts of the index. PostgreSQL 18 adds a built-in alternative: uuidv7() , which generates a time-ordered UUID. That makes UUIDv7 worth considering for new tables—but it is not a universal performance fix, a precise event clock, or a secret identifier. What UUIDv7 changes A UUID is still 128 bits. In UUIDv7, the most significant 48 bits encode a Unix timestamp in milliseconds. The remaining bits contain random data and may include implementation-specific monotonicity information. This puts values generated around the same time near one another when compared in their standard byte order. The RFC describes UUIDv7 as time-ordered and notes that random UUID versions can have poor database-index locality. PostgreSQL 18 provides uuidv7...

Your Spring Boot Transaction Doesn't Make Event Publishing Reliable A request marks an order as paid and then publishes an OrderPaid event. Both calls may succeed in a normal test. But the database and a message broker are separate systems: the database can commit while the broker is unavailable, or the broker can accept a message just before the database transaction rolls back. A Spring @Transactional method does not, by itself, make those two systems one atomic transaction. This gap is a common source of events that are missing, duplicated, or inconsistent with the business record. A transactional outbox narrows the gap by making the business change and the intent to publish an event part of the same database transaction. Write the event intent with the business change Instead of calling the broker inside the request's database transaction, insert a durable outbox row alongside the order update: BEGIN; UPDATE orders SET status = 'PAID' WHERE id = :order_id; INSE...

Rest Is Not a Reward for Finishing Everything There is always one more thing to do. An email waits unanswered, a room still needs attention, or a task has slipped into tomorrow. If rest begins only when every responsibility is finished, it may never begin at all. Scripture offers a different starting point: rest is not a prize we earn by completing enough work. It is a gift and a command that remind us who made us, who provides for us, and where our hope finally rests. Rest begins with God's completed work Genesis describes God resting on the seventh day after completing his work of creation. This is not a picture of God recovering from exhaustion. His work is complete; he blesses the day and sets it apart. The rhythm of work and rest is built into the story of creation before it is given to Israel as a command. That pattern tells us something humbling: we are creatures, not the keepers of the universe. Our work matters, but it is not what holds all things together. Stopping ca...

Spring Boot @Async: Fixing Distributed Tracing Context Propagation Across Threads Have you ever noticed that distributed traces suddenly disappear when your Spring Boot application executes an asynchronous task? A request enters your application, calls a service, and then schedules background work using @Async . The initial request appears correctly in your tracing dashboard, but the background execution is missing—or worse, it appears as an entirely unrelated trace. The problem may not be your tracing backend. It may be that the request's observation context was not propagated to the worker thread. Distributed tracing relies on context: identifiers and other state that connect operations across services and execution boundaries. OpenTelemetry provides mechanisms to propagate this context between services, usually without requiring application code to copy identifiers manually. However, there is another boundary within the same application that is easy to overlook: switching thre...

Publish npm Packages from GitHub Actions Without NPM_TOKEN: Using Trusted Publishing with OIDC Publishing an npm package through GitHub Actions traditionally requires a secret such as NPM_TOKEN . While this approach works, it also means storing a reusable publishing credential in your repository's automation configuration. There is a better alternative: npm Trusted Publishing . With Trusted Publishing, GitHub Actions authenticates to npm using OpenID Connect (OIDC). Instead of storing a long-lived npm publish token, GitHub identifies the workflow, and npm verifies whether that workflow is authorized to publish the package. The practical benefit is reduced credential exposure. Your release workflow no longer needs a long-lived npm publishing secret. This does not guarantee that your package or workflow is secure, but it removes one persistent credential from the release process. How npm Trusted Publishing Works The process relies on a trust relationship between npm and GitHub Acti...