DEV Community: Onur Cinar

The Go Validator Blind Spot: Invisible Characters and Unicode Lookalikes

Onur Cinar — Sun, 06 Sep 2026 16:01:14 +0000

A username that reads "admin" on every screen you check it on can be storing something else entirely -- and it'll sail past a reserved-name check that's doing exactly what it was told. Most Go validation stacks have no way to catch it. Here's why, and two small normalizers that close the gap.

Here's a username: ‮nimda‬. Depending on how your browser renders bidirectional text, that might already display as admin — which is the entire point. Read it in a user list, a support ticket, or an audit log, and every person who looks at it will tell you the account is named admin. Now compare it to the literal string, the way a reserved-name check normally works:

spoofed := "‮nimda‬" // renders as "admin" wherever bidi text is displayed

fmt.Println(spoofed == "admin") // false
fmt.Println(len([]rune(spoofed))) // 7, not 5

It isn't "admin". It's the five letters n, i, m, d, a — in that literal order — wrapped in two invisible bidirectional control characters, U+202E (right-to-left override) and U+202C (pop directional formatting). Unicode reserves those for rendering Arabic and Hebrew correctly. Wrapped around plain Latin letters instead, they just flip the visual order: nimda, laid out right-to-left, reads admin.

A reserved-username check that rejects the exact string "admin" lets this straight through — correctly, by its own logic, since the string genuinely isn't "admin". Nothing here is a bug in checker, or in any other Go validation library, or even in Unicode. The check did exactly what it was told. The problem is one level up: it was never asked whether the string secretly contains characters that don't correspond to anything the comparison sees but everyone looking at a screen does.

This is not a new attack

The trick behind that username has a name: in November 2021, researchers at Cambridge published Trojan Source (CVE-2021-42574), showing that the same bidirectional control characters can be slipped into source code to make it compile one way and display another way to a human reviewer. The characters are identical; only the target changes. Anything a person reads back instead of a compiler — a username, a chat message, a support ticket, a PR title — is just as susceptible.

A narrower, older trick uses zero-width characters instead of bidi ones: insert a zero-width space or zero-width joiner into a blocklisted word and a naive filter no longer matches it, even though the word displays unchanged. It's a standard way spam and moderation filters get evaded, and it works against a validation struct tag exactly as well as it works against a regex.

The other half of the problem: it doesn't need to be invisible at all

Zero-width characters are the sharp case, but plain Unicode gives you the same problem with characters you can see. "ALICE", "ＡＬＩＣＥ" (fullwidth Latin letters), and a version using ligatures or Roman numerals in place of ordinary letters are three different byte sequences that a human reading them would call the same word. A uniqueness check, a keyword filter, or a duplicate-handle guard that only compares strings byte-for-byte treats all three as unrelated.

This isn't hypothetical, either — fullwidth-character substitution is a known way to slip a blocked command past a keyword-based filter (ｒｍ　－ｒｆ　／ reads as rm -rf / to anyone who looks at it, and normalizes right back to it), and several platforms have had to retrofit Unicode normalization after discovering it let people register visually-identical duplicate usernames.

None of this is because validation is careless. required, min-len, an exact-match reserved-name rule — every one of them is a byte-level check, and byte-level checks were never asked a different question: does this string contain characters that don't correspond to anything the person reading it actually typed? That's a normalization problem, not a validation one. It needs its own step in the pipeline, before anything else looks at the value.

Two checkers, two different problems

checker added two normalizers for this, deliberately kept separate because they solve different problems and have different costs.

strip-invisible (core module, no dependency) removes zero-width space, zero-width non-joiner, zero-width joiner, word joiner, the zero-width no-break space (BOM), and the bidirectional embedding/override/isolate controls behind Trojan Source:

type Handle struct {
    Name string `checkers:"trim strip-invisible required min-len:3"`
}

h := &Handle{Name: "adm‌in"}
checker.CheckStruct(h)
// h.Name is now "admin" -- five runes, matches the literal string.

unmasked, _ := checker.StripInvisible("‮nimda‬")
fmt.Println(unmasked)          // nimda
fmt.Println(unmasked == "admin") // false -- and now it doesn't even display like it

Run the username from the opening through it and the disguise falls apart: strip-invisible doesn't know or care what the override characters were trying to accomplish, it just removes them — leaving the honest nimda, which no longer reads as admin in any renderer.

nfkc (an opt-in module — it needs golang.org/x/text/unicode/norm, so it's kept out of the dependency-free core) applies Unicode Normalization Form KC: it folds compatibility characters — fullwidth forms, ligatures, and similar stylistic variants — into their canonical equivalents:

import _ "github.com/cinar/checker/v2/nfkc"

type Handle struct {
    Name string `checkers:"trim nfkc required min-len:3"`
}

a := &Handle{Name: "ＡＬＩＣＥ"}
checker.CheckStruct(a)
// a.Name is now "ALICE"

waf, _ := nfkc.Normalize("ｒｍ　－ｒｆ　／")
// waf is "rm -rf /"

Both are one word in a checkers tag. Neither needs a second pass over your validation logic — they sit in the same pipeline as trim, lower, and required, because normalizers and checkers are the same function type in this library and can be freely mixed.

What this does not fix

Be precise about what NFKC actually covers, because it's narrower than "Unicode spoofing" in general. NFKC only folds characters that are compatibility-equivalent under the Unicode standard — the same letter, rendered differently. It does nothing for homoglyphs: characters that are visually similar but come from a different script entirely, like a Cyrillic а (U+0430) standing in for a Latin a (U+0061). Those two are not NFKC-equivalent, so paypal.com spelled with a Cyrillic а normalizes right back to itself — still spoofed.

Catching that class of lookalike needs a confusables check — Unicode UTS #39's skeleton algorithm, which maps visually similar characters across scripts to a shared representative form before comparing. It's a genuinely different, heavier piece of machinery than either normalizer here, and checker doesn't currently provide it. If cross-script impersonation is part of your threat model — a login handle, a domain-like identifier — strip-invisible plus nfkc narrows the problem but doesn't close it.

Where to apply this, and where not to

Both normalizers are opinionated about removing or rewriting characters, which means they're right for the fields where an invisible or compatibility character is never legitimate — a username, a handle, a search keyword, an API key — and wrong for general free-text content. Zero-width joiner is load-bearing in emoji sequences; zero-width non-joiner has real uses in Persian and other scripts. Running strip-invisible over a chat message body or a comment field will quietly corrupt text some of your users actually rely on. Point these at identifiers, not prose.

type Registration struct {
    Handle string `checkers:"trim strip-invisible nfkc required min-len:3 alphanumeric"`
    Bio    string `checkers:"trim max-len:500"` // free text -- neither normalizer applies here
}

strip-invisible ships in Checker's core module; nfkc is a separate, opt-in module at github.com/cinar/checker/v2/nfkc, so the dependency it needs never touches a codebase that doesn't ask for it.

Catch Bad Validation Tags at Compile Time with checkerlint

Onur Cinar — Sun, 06 Sep 2026 03:40:00 +0000

Struct tags are just strings — a typo'd checker name, a wrong-typed field, or a renamed cross-field target all compile fine and fail silently at runtime. checkerlint catches all three before you ship.

Struct tags are string literals. The Go compiler checks that your struct compiles — it has no idea what checkers:"eq-field:Passwrd" means, so a typo in a field name, a checker applied to a field of the wrong type, or a renamed field that a cross-field rule still points at all compile fine. They fail later, at runtime, sometimes silently, sometimes as a panic in the middle of handling a request.

type Registration struct {
    Password        string `checkers:"trim required"`
    ConfirmPassword string `checkers:"required eq-field:Passwrd"` // typo: no such field
    Age             int    `checkers:"email"`                     // email is string-only
}

Nothing here trips go build, go vet, or a normal linter — they all treat checkers:"..." as an opaque string. The first bug only surfaces the moment someone submits a registration form and eq-field can't find a field called Passwrd. The second is worse: email assumes a string under the hood, so calling it on an int field panics at validation time instead of returning a normal error.

checkerlint is a go/analysis-based static analyzer, shipped as its own module in the Checker repo, that reads these tags at build/lint time and catches exactly this class of bug before it ships:

./registration.go:3:2: checkerlint: eq-field references field "Passwrd", which doesn't exist on this struct
./registration.go:4:2: checkerlint: email requires a string, but the field's type is int

What it actually checks

Three things, all specific to how checkers/validate tags can go wrong:

Unknown checker names. Every token in the tag has to be a registered checker, normalizer, field-relative checker, omitempty, or a name your own code registered via RegisterMaker/RegisterFieldMaker with a string literal. Typo requird instead of required and checkerlint flags it — nothing else in your toolchain will.
Type compatibility. A well-scoped set of built-ins panic at runtime on the wrong kind — string-only checkers (email, trim, url, and friends) and numeric-only ones (gt, gte, lt, lte). checkerlint checks the tagged field's actual type against what the checker expects, including through one level of pointer indirection and through a slice/array/map's element type for item-level tokens.
Cross-field targets. eq-field, after-field, before-field, required-if, and required-unless all name a sibling field by string. checkerlint confirms that field actually exists on the struct — including, on a best-effort basis, embedded/anonymous fields — so a rename doesn't silently leave a dangling reference.

It knows the built-in vocabulary from whichever version of github.com/cinar/checker/v2 your code is built against, so it stays in sync automatically as new checkers ship. It can't see a checker registered only at runtime in a separate package, or one whose name is built from a non-literal expression — both are edge cases outside what static analysis can reach.

Running it

Install the standalone binary:

go install github.com/cinar/checker/v2/checkerlint/cmd/checkerlint@latest

Run it like go vet — same flags, same package patterns:

checkerlint ./...

Or plug it into go vet directly as a vet tool:

go vet -vettool=$(which checkerlint) ./...

Wiring it into golangci-lint

If your CI already runs golangci-lint, add checkerlint as a module plugin (golangci-lint v2's plugin system) instead of a separate step:

# .golangci.yml
version: "2"
linters:
  settings:
    custom:
      checkerlint:
        type: module
        path: github.com/cinar/checker/v2/checkerlint
        settings: {}

Module-plugin build steps have shifted across golangci-lint releases, so check its module-plugin docs for the exact setup your version expects — the .golangci.yml shape above is the stable part.

Why this matters more than it sounds like

Every struct-tag-driven validation library has this exact blind spot — go-playground/validator, ozzo-validation, all of them. The tags are strings; the compiler can't see inside them. Most teams find out about a typo'd checker name or a stale cross-field reference the way you'd expect: a bug report, or a support ticket about a validation rule that "just doesn't work," usually for a code path that isn't covered by a test with that exact malformed input.

checkerlint moves that failure from "someone hits it in production" to "the linter fails your PR." That's a category of bug — silently wrong or panicking struct tags — that the rest of the Go toolchain has no way to see, closed at the point where it's cheapest to fix.

Try it

go install github.com/cinar/checker/v2/checkerlint/cmd/checkerlint@latest
checkerlint ./...

Full details, including exactly which checkers are type-checked, are in the checkerlint README. It's a separate, independently versioned module — adding it to your CI doesn't add a single dependency to the core checker library your code actually imports.

Returning RFC 9457 Problem Details from Go Validation Errors

Onur Cinar — Sun, 06 Sep 2026 03:32:51 +0000

How to turn struct-tag validation failures into a standard "application/problem+json" response — the RFC 9457 format — with one method call, no hand-rolled error envelope.

Most Go APIs invent their own validation error shape. One team returns {"errors": [...]}, another {"field_errors": {...}}, a third just a flat {"error": "message"} and hopes the client parses it. Every one of those is a private contract the client has to learn from your docs, because there's no shared shape for "here's what's wrong with your request."

RFC 9457 — Problem Details for HTTP APIs — is the IETF standard that fixes this: a application/problem+json body with type, title, status, and room for problem-specific extensions. Checker now builds one of these directly from a failed struct validation, via CheckErrors.ProblemDetails().

The shape

RFC 9457 defines four base members — type, title, status, detail, instance — and lets a specific problem type add its own. For validation errors, RFC 9457 §3.1 sketches exactly this extension: an invalid-params array listing which fields failed and why. That's what Checker produces.

From a failed struct to a problem+json body

Take a struct with a missing required field:

type Person struct {
    Name string `checkers:"required"`
}

person := &Person{}

errs, ok := checker.CheckStruct(person)
if !ok {
    data, _ := json.Marshal(errs.ProblemDetails())
    fmt.Println(string(data))
}

{
  "type": "about:blank",
  "title": "Your request parameters failed validation.",
  "status": 400,
  "invalid-params": [
    { "name": "Name", "reason": "Required value is missing.", "code": "REQUIRED" }
  ]
}

One method call — errs.ProblemDetails() — turns the same CheckErrors you'd otherwise call .JSON() on into a *ProblemDetails value, ready to marshal. type defaults to "about:blank" (RFC 9457's own default for "no more specific problem type registered"), status defaults to 400, and each invalid-params entry carries the field name, a localized human-readable reason, and the machine-readable code — the same code you'd branch on client-side with the plain .JSON() output.

Wiring it into a handler

The one thing RFC 9457 requires that a plain JSON body doesn't is the content type:

func signupHandler(w http.ResponseWriter, r *http.Request) {
    var req SignupRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "invalid JSON", http.StatusBadRequest)
        return
    }

    errs, valid := checker.CheckStruct(&req)
    if !valid {
        pd := errs.ProblemDetails()

        w.Header().Set("Content-Type", "application/problem+json")
        w.WriteHeader(pd.Status)
        json.NewEncoder(w).Encode(pd)
        return
    }

    w.WriteHeader(http.StatusCreated)
}

pd.Status drives both the header and the body, so they can't drift out of sync.

Overriding the defaults

Type, Title, and Status are plain exported fields on the returned *ProblemDetails — RFC 9457 deliberately leaves them to the API producer, so Checker fills in reasonable defaults and gets out of your way. Set them before marshaling if you want a registered problem type or a different status code:

pd := errs.ProblemDetails()
pd.Type = "https://api.example.com/problems/validation-error"
pd.Title = "Signup request failed validation"
pd.Status = http.StatusUnprocessableEntity // 422 instead of 400

Nothing else about the call changes — invalid-params is still built from the same CheckErrors map.

Localized problem details

Since ProblemDetails() is just ProblemDetailsWithLocale(DefaultLocale) under the hood, a localized variant is one argument away — same 23 locales that back JSONWithLocale:

pd := errs.ProblemDetailsWithLocale(locales.DeDE)

The reason strings come back in German; type, status, and code are untouched, since those aren't meant for display.

Why bother with a standard shape

A hand-rolled error envelope works fine until you have more than one API, or a client library trying to handle errors generically, or an API gateway that wants to do something useful with 4xx bodies without special-casing your service. application/problem+json is already understood by tooling in several ecosystems — Spring, ASP.NET Core, and various API gateways emit or consume it natively — so producing it from Go costs you nothing extra (it's the same validation you were already running) and buys you a body shape other tools don't have to be taught.

Try it

go get github.com/cinar/checker/v2

import checker "github.com/cinar/checker/v2"

ProblemDetails() and ProblemDetailsWithLocale() sit right next to JSON() and JSONWithLocale() on CheckErrors — pick whichever body shape your API needs, from the same validation call. Full details in the README.

Struct Tag Validation in Go: A Practical Guide

Onur Cinar — Sun, 06 Sep 2026 03:26:27 +0000

A hands-on walkthrough of validating and normalizing a real signup form in Go — trimming input, cross-field rules, slices, custom messages, and JSON error responses — using struct tags.

Every Go API ends up needing the same thing: take a JSON body, clean it up, make sure it's valid, and tell the client exactly what's wrong if it isn't. This guide walks through building that for a real signup form, using struct tags instead of hand-written if chains, with Checker as the tool doing the work.

By the end you'll have a SignupRequest that trims and lowercases its own input, validates it, enforces a cross-field password match, checks a slice of roles, returns friendly per-field error messages, and serializes cleanly to JSON — in about 15 lines of tags.

Setup

go get github.com/cinar/checker/v2

import checker "github.com/cinar/checker/v2"

Step 1: A struct with checkers, not `if` statements

Start with a plain struct and describe each field's rules as a checkers tag:

type SignupRequest struct {
    Email           string `json:"email" checkers:"trim lower required email"`
    Password        string `json:"password" checkers:"required min-len:8"`
    ConfirmPassword string `json:"confirm_password" checkers:"required eq-field:Password"`
}

Read a tag left to right — it's a pipeline, executed in order:

trim lower required email on Email: trim whitespace, lowercase it, make sure something is left, then check it looks like an email. Order matters here — required runs after trim, so a field of just " " correctly fails.
required min-len:8 on Password: must be present, must be at least 8 characters.
required eq-field:Password on ConfirmPassword: must be present, and must equal the sibling Password field.

Note that eq-field isn't comparing against a hardcoded value — it's reading another field off the same struct at validation time. That's a "field-relative" checker; Checker also ships after-field, before-field, required-if, and required-unless for the same pattern (a state field required only when country is "US", a return date that has to be after a departure date, and so on).

Step 2: Validate it

func main() {
    req := &SignupRequest{
        Email:           "  ALICE@EXAMPLE.COM  ",
        Password:        "supersecret123",
        ConfirmPassword: "supersecret123",
    }

    errs, valid := checker.CheckStruct(req)
    if !valid {
        data, _ := errs.JSON()
        fmt.Println(string(data))
        return
    }

    fmt.Println(req.Email) // "alice@example.com"
}

CheckStruct does two things in one pass: it normalizes the struct in-place and validates it. Look at req.Email after the call — it's already trimmed and lowercased, ready to hash the password against or write to a database, with no separate "sanitize" step beforehand.

If validation fails, errs is a CheckErrors — a map[string]error keyed by field name, which also implements error itself, so you can return errs directly from a function that expects one. Calling .JSON() on it gives you an HTTP-API-ready body:

{
  "Password": {
    "code": "NOT_MIN_LEN",
    "message": "Value cannot be less than 8."
  }
}

Machine-readable code for client-side logic, human-readable message for display — per field, no manual formatting.

Step 3: Add a slice field

Signup forms often collect more than scalars. Say SignupRequest also takes a list of roles, capped at 3, each one trimmed and alphanumeric-only:

type SignupRequest struct {
    Email           string   `json:"email" checkers:"trim lower required email"`
    Password        string   `json:"password" checkers:"required min-len:8"`
    ConfirmPassword string   `json:"confirm_password" checkers:"required eq-field:Password"`
    Roles           []string `json:"roles" checkers:"@max-len:3 trim alphanumeric"`
}

The @ prefix is what separates container-level rules from item-level ones in the same tag. @max-len:3 caps the slice at three entries; trim alphanumeric (no @) runs on every individual string inside it. Given Roles: []string{" admin ", "editor!"}, after CheckStruct runs, Roles[0] becomes "admin" and Roles[1] fails alphanumeric because of the !. The same @ split works for maps, and nested structs inside slices/maps are walked recursively — this isn't a top-level-fields-only validator.

Step 4: Make a field optional

Not every field should be required. Add an optional website field:

Website string `json:"website" checkers:"omitempty url"`

omitempty skips every other checker in the tag when the field is its zero value, but still runs them normally once a value is present. An empty Website is fine; "not-a-url" is not. It looks at the field's original value, so trim omitempty required on an all-whitespace string still fails required after trimming — whitespace isn't the zero value to begin with. (Don't pair omitempty with required on the same field — that's a contradiction, and omitempty wins, so required never runs.)

Step 5: Give one field a friendlier error message

The default messages are fine for logs, but a signup form probably wants nicer copy for Email specifically. Add a checkersMsg tag alongside checkers — a semicolon-separated list of name=message pairs, keyed by the bare checker name:

Email string `json:"email" checkers:"trim lower required email" checkersMsg:"required=Email is required;email=Enter a valid email address"`

This overrides the message only for this field, only for these checkers — every other field using required or email elsewhere in your codebase keeps the default (or localized) wording.

Step 6: Wire it into an HTTP handler

Put it all together with the standard library — no framework required:

func signupHandler(w http.ResponseWriter, r *http.Request) {
    var req SignupRequest
    if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
        http.Error(w, "invalid JSON", http.StatusBadRequest)
        return
    }

    errs, valid := checker.CheckStruct(&req)
    if !valid {
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusBadRequest)
        data, _ := errs.JSON()
        w.Write(data)
        return
    }

    // req is normalized and valid — safe to persist.
    w.WriteHeader(http.StatusCreated)
}

If you're on Gin or Echo instead, the separately-versioned adapter modules collapse decode-and-validate into one call:

import checkergin "github.com/cinar/checker/v2/gin"

router.POST("/signup", func(c *gin.Context) {
    var req SignupRequest
    if !checkergin.Bind(c, &req) {
        return // 400 already written
    }
    c.JSON(http.StatusOK, req)
})

What you get for free once the tags exist

Because the rules live as tags on the type rather than scattered across handler code, they're reusable outside validation itself. checker.JSONSchema(&SignupRequest{}) walks the same tags and produces a Draft 2020-12 JSON Schema document — required becomes required, min-len becomes minLength, email becomes format: "email" — so your Go validation rules can double as API documentation or a frontend contract, instead of being hand-copied into a second place that quietly drifts out of sync.

Try it yourself

go get github.com/cinar/checker/v2

There's a runnable version of the core trim/validate/cross-field pattern on the Go Playground, and the full checker list — 30+ built-ins covering emails, URLs, IPs, credit cards, hashes, country codes, and more — is in the README. If a rule you need isn't built in, RegisterMaker lets you add your own and it behaves exactly like a first-party checker in struct tags.

Stop Hand-Rolling Validation in Go — Meet Checker

Onur Cinar — Sat, 05 Sep 2026 04:23:29 +0000

If you've written more than one HTTP handler in Go, you've written this code:

if strings.TrimSpace(req.Name) == "" {
    return errors.New("name is required")
}

if !strings.Contains(req.Email, "@") {
    return errors.New("invalid email")
}

if req.ConfirmPassword != req.Password {
    return errors.New("passwords do not match")
}

It starts small. Then a new field shows up, then a cross-field rule, then someone asks for a nicer error message, then someone else asks for that error message in Spanish, and suddenly your handler is 200 lines of if statements that nobody wants to touch.

Checker is a Go library built to make that pile of if statements disappear — declaratively, with zero external dependencies. Here's why it's worth a look.

The one-line pitch

type Registration struct {
    Name            string `checkers:"trim required"`
    Email           string `checkers:"required email"`
    Password        string `checkers:"required min-len:8"`
    ConfirmPassword string `checkers:"eq-field:Password"`
}

errors, valid := checker.CheckStruct(&registration)
if !valid {
    // errors is a map[string]error, keyed by field name
}

That's it. Trim the name, require it, validate the email format, enforce a minimum password length, and confirm the two password fields match — all declared next to the field they apply to, all in one call.

Why it's worth your attention

Zero dependencies, really zero

The core checker module imports nothing beyond the Go standard library. Not reflect-based validator forks with a dozen transitive deps, not a YAML parser you didn't ask for. go get github.com/cinar/checker/v2 pulls in exactly one thing: Checker itself. That matters for supply-chain surface area, build times, and not having to explain to a security review why your validation library needs 40 packages.

Checkers and normalizers, in one pipeline

Most validation libraries only check — they tell you your input is wrong. Checker also fixes it. trim, lower, upper, title, HTML/URL escaping — these are normalizers, and they share the exact same pipeline as checkers like required or email. Mix them freely:

type Person struct {
    Name string `checkers:"trim title required"`
}

Trim the whitespace, title-case it, then make sure something is actually left. One declaration, no separate "sanitize" pass before your "validate" pass.

Cross-field and conditional rules, without a callback

A password-confirmation field. A "State" field that's only required if "Country" is "US". A return date that has to be after the departure date. These usually mean dropping out of struct tags entirely and writing custom validation functions. Checker handles them as tags:

type Trip struct {
    Country  string `checkers:"required"`
    State    string `checkers:"required-if:Country:US"`
    DepartAt string `checkers:"required"`
    ReturnAt string `checkers:"required after-field:DateOnly:DepartAt"`
}

eq-field, required-if, required-unless, before-field, after-field — all comparing sibling struct fields, all declared inline.

Slices and maps, checked at both levels

Need to make sure a slice has at most 2 emails, and that each email is at most 64 characters? The @ prefix separates container-level rules from item-level ones:

type Person struct {
    Emails map[string]string `checkers:"@max-len:2 trim max-len:64"`
}

@max-len:2 caps the map at two entries. trim max-len:64 runs on every value in it. Nested structs and pointers inside a slice or map get walked and checked too — this isn't a shallow, top-level-fields-only validator.

23 languages, opt-in

Ship a SaaS product to a global audience and "Not a valid email address." in every locale stops being acceptable pretty fast. Checker ships 23 translated locales out of the box — the same set go-playground/validator supports — and none of them cost you anything unless you ask for them:

checker.RegisterLocale(locales.DeDE, locales.DeDEMessages)

_, err := checker.IsEmail("abcd")
fmt.Println(err.ErrorWithLocale(locales.DeDE))
// Keine gültige E-Mail-Adresse.

Only en-US is registered by default, so importing checker never silently pulls translation data into your binary that you don't use.

Structured errors that are API-ready

CheckStruct doesn't just hand you a generic error. It returns CheckErrors, a map[string]error keyed by field name that also implements the error interface, so you can return it directly. When you're building an HTTP API, call .JSON() and you're done:

errs, valid := checker.CheckStruct(&registration)
if !valid {
    data, _ := errs.JSON()
    w.WriteHeader(http.StatusBadRequest)
    w.Write(data)
    // {"Name":{"code":"REQUIRED","message":"Required value is missing."}}
    return
}

Machine-readable code, human-readable message, per field, ready to serialize. JSONWithLocale() does the same thing localized.

Your validation rules, turned into a JSON Schema — for free

This is the feature that stops people mid-scroll: Checker can generate a JSON Schema document directly from your struct tags.

type Person struct {
    Name  string `json:"name" checkers:"trim required"`
    Email string `json:"email" checkers:"required email"`
}

schema := checker.JSONSchema(&Person{})

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Person",
  "type": "object",
  "properties": {
    "email": { "type": "string", "format": "email" },
    "name": { "type": "string" }
  },
  "required": ["email", "name"]
}

required becomes required, min-len/max-len become minLength/maxLength (or minItems/maxItems, minProperties/maxProperties for slices and maps), gte/lte become minimum/maximum, and email/url/ipv4/fqdn become a format. A checker with no schema equivalent isn't silently dropped — it lands in an x-checker vendor extension so nothing goes missing.

Translation: your Go validation tags are your API documentation and your frontend validation spec. Stop maintaining the same rules three times.

Drop-in adapters for Gin and Echo

If you're on Gin or Echo, binding and validating a request body is one call:

import checkergin "github.com/cinar/checker/v2/gin"

router.POST("/register", func(c *gin.Context) {
    var registration Registration

    if !checkergin.Bind(c, &registration) {
        return // 400 already written
    }

    c.JSON(http.StatusOK, registration)
})

Both adapters are separately-versioned Go modules, so Gin or Echo only enters your dependency tree if you actually go get the adapter — the core library stays dependency-free regardless of which framework you use.

Extensible when the built-ins aren't enough

Checker ships 30+ checkers (email, URL, IP/IPv4/IPv6, CIDR, MAC, credit card, ISBN, hashes, country and language codes, an Ethereum address checker, and more), but you're not boxed in. Register your own:

checker.RegisterMaker("is-fruit", func(params string) checker.CheckFunc[reflect.Value] {
    return func(value reflect.Value) (reflect.Value, error) {
        s := value.Interface().(string)
        if s == "apple" || s == "banana" {
            return value, nil
        }
        return value, checker.NewCheckError("NOT_FRUIT")
    }
})

Once registered, is-fruit works in struct tags exactly like a built-in checker — and you can teach JSONSchema how to represent it too, via RegisterSchemaMaker.

Built like a library that means it

A detail that's easy to gloss over: this project enforces 100% test coverage. Every checker, every normalizer, every branch has a matching test. There's also a locales_test.go that fails the build if any locale is missing a message for a given error code, or if a placeholder doesn't match en-US. That's the kind of quiet discipline that keeps a validation library from lying to you in production.

Try it

go get github.com/cinar/checker/v2

import checker "github.com/cinar/checker/v2"

Check out the project on GitHub: github.com/cinar/checker

If you're validating structs by hand in Go right now, give it five minutes. If you find a checker missing, or a locale that's rough around the edges — PRs are welcome.

Self-Evolving Apps: Not Vibe, Live-Coding in Ruby with LLMs and Metaprogramming

Onur Cinar — Wed, 12 Aug 2026 05:28:04 +0000

Using AI to generate code for a new application is a familiar workflow today. But what if an application starts as a completely blank slate, learning on the job and writing its own implementation live as you call nonexistent methods?

This concept of live-patching and zero-downtime execution isn't entirely new. Early in my career at Nortel Networks, I have seen this with PROTEL (PRocess Oriented TELepony language), a proprietary language designed for telecom switches. To achieve "five nines" (99.999%) availability, you couldn't simply take systems offline for deployments—code updates had to happen via live hot-patching. Later on, I thoroughly enjoyed similar live code reloading capabilities while working with Erlang.

Recently, as I spent more time with Ruby, its rich metaprogramming capabilities got me thinking: What if we start with an empty Ruby object, and as we call methods on it, it uses an LLM to write and evaluate its own code on the fly?

1. The Blank Slate

Let's start with a completely empty class:

class Dummy < LiveCode
end

Now, let's fire up irb (Ruby's REPL) and start interacting with our dummy object as if the methods already existed:

dummy = Dummy.new
dummy.add(1, 2)

At this point, Ruby will complain because Dummy doesn't have an add method. However, the method name (add) and its arguments (1, 2) clearly communicate our intent.

Ruby provides a built-in hook called method_missing to catch calls to undefined methods. This is where we bring in AI. To interact with our LLM provider, we'll use the excellent RubyLLM gem.

2. Dynamic Method Generation via `method_missing`

To make this behavior reusable across objects, we put our logic inside a LiveCode base class that Dummy inherits from.

Here is our initial LiveCode implementation:

class LiveCode
  def method_missing(method_name, *args, **kwargs)
    p "Missing method: #{method_name}, #{args.inspect}, #{kwargs.inspect}"

    prompt = <<~PROMPT
      You are a Ruby code generator. A missing method `#{method_name}` was called
      with the arguments: #{args.map(&:class)}, keyword arguments: #{kwargs.keys}.

      Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
      Example:
      def #{method_name}(...)
        # implementation
      end
    PROMPT

    ruby_code = @chat.ask(prompt).content

    # Evaluate the generated Ruby code directly on the instance's singleton class
    singleton_class.class_eval(ruby_code)

    # Re-dispatch the original method call now that it exists!
    send(method_name, *args, **kwargs)
  end
end

How It Works

Interception: When dummy.add(1, 2) is called, method_missing intercepts the call and extracts the method name (:add) and parameter types (Integer, Integer).
LLM Prompting: We construct a prompt instructing the model to return only valid Ruby code defining the method.
Metaprogramming: We use singleton_class.class_eval(ruby_code) to inject the generated method into our object at runtime.
Re-dispatch: Finally, send(method_name, ...) invokes the newly defined method seamlessly!

3. Seeing It in Action

Let's test this in IRB:

irb(main):003> dummy.add(1, 2)

"Missing method: add, [1, 2], {}"

"Prompt: You are a Ruby code generator. A missing method `add` was called
with the arguments: [Integer, Integer], keyword arguments: [].

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def add(...)
  # implementation
end
"

"Code: def add(a, b)
  a + b
end"

=> 3

In real-time, the LLM synthesized def add(a, b); a + b; end, registered it on dummy, executed it, and returned 3. Subsequent calls to dummy.add(1, 2) will execute instantly without hitting method_missing again!

4. Adding Context: State and Inter-Method Dependencies

A real object has multiple methods that need to share state via instance variables and interact with one another. To enable this, our LLM needs context about existing instance variables, their types, and previously generated methods.

We introduce a helper method llm_context to capture this state:

def llm_context
  context = "# Current Instance Variables and Types:\n"
  if instance_variables.empty?
    context += "(No instance variables yet)\n"
  else
    instance_variables.each do |name|
      value = instance_variable_get(name)
      context += " - #{name}: #{value.class.name}\n"
    end
  end

  context += "# Previously Generated Methods:\n"
  if @_generated_methods.nil? || @_generated_methods.empty?
    context += "(No generated methods yet)\n"
  else
    @_generated_methods.each do |name, code|
      context += "#{code}\n"
    end
  end

  context
end

We then update our prompt to include this rich context:

prompt = <<~PROMPT
  You are a Ruby code generator. A missing method `#{method_name}` was called
  with the arguments: #{args.map(&:class)}, keyword arguments: #{kwargs.keys}.

  Write ONLY the valid Ruby code to define `#{method_name}`. Ensure it works
  well with the existing instance variables and previously generated methods.

  #{llm_context}

  Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
  Example:
  def #{method_name}(...)
    # implementation
  end
PROMPT

5. Stateful Walkthrough: Setters & Getters

Let's test setting a property and then retrieving it in a subsequent call.

Step 1: Setting a Value

irb(main):003> dummy.name = "Onur"

"Missing method: name=, [\"Onur\"], {}"
"Prompt: You are a Ruby code generator. A missing method `name=` was called
with the arguments: [String], keyword arguments: [].

Write ONLY the valid Ruby code to define `name=`. Ensure it works
well with the existing instance variables and previously generated methods.

# Current Instance Variables and Types:
 - @chat: RubyLLM::Chat
# Previously Generated Methods:
(No generated methods yet)

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def name=(...)
  # implementation
end
"

"Code: def name=(value)
  @name = value
end"

=> "Onur"

Calling dummy.name = "Onur" dynamically created the setter method name=(value) which initialized the @name instance variable.

Step 2: Reading the Value

irb(main):004> dummy.name

"Missing method: name, [], {}"
"Prompt: You are a Ruby code generator. A missing method `name` was called
with the arguments: [], keyword arguments: [].

Write ONLY the valid Ruby code to define `name`. Ensure it works
well with the existing instance variables and previously generated methods.

# Current Instance Variables and Types:
 - @chat: RubyLLM::Chat
 - @_generated_methods: Hash
 - @name: String
# Previously Generated Methods:
def name=(value)
  @name = value
end

Return ONLY valid Ruby code defining this method. Do not include markdown formatting.
Example:
def name(...)
  # implementation
end
"

"Code: def name
  @name
end"

=> "Onur"

Because our prompt included @name: String and the previously defined name=(value) method, the LLM understood the context and generated the exact matching getter method def name; @name; end.

What's Next?

This experiment demonstrates how easily Ruby's dynamic nature combines with LLMs to build self-assembling objects. There are a few natural next steps for expanding this idea—such as persisting the generated code to disk, adding sandboxing/security checks, or enabling feedback loops to auto-fix runtime errors.

Source Code & Examples

The complete working source code for this post is available in the site repository:

https://zdo.com/blog/posts/self-evolving-app-code/

Stop Choosing One AI Coding Assistant: How I Pair Gemini CLI and OpenCode for Better Code

Onur Cinar — Sat, 02 May 2026 20:28:25 +0000

If you’re like me, you’ve toggled between AI coding assistants trying to find the "best" one. Gemini generates features fast, while OpenCode’s models are good for catching edge cases. But why choose?

I built a custom workflow using Gemini CLI to orchestrate three specialized agents that bridge these two worlds. Here’s how I get the best of both: Gemini's speed for implementation and OpenCode's rigor for review.

The Three-Agent Setup

My .agents directory contains three distinct roles. The magic of Gemini CLI is its ability to not only write code but also manage other CLIs and agents:

code-writer (Gemini-powered): The primary builder. It handles the heavy lifting of implementation and iterates on feedback.
opencode-code-reviewer (Gemini-powered): The "Bridge Agent." This Gemini agent knows how to run the opencode CLI, capture its feedback, and hand it back to the writer.
code-reviewer (OpenCode-powered): The "Expert Reviewer." This is the native agent inside OpenCode that provides the actual technical critique.

The Workflow (Step by Step)

This setup allows me to move from an issue to a verified PR with just two main commands:

Step 1: Implementation

I start by asking Gemini to implement the feature:

Use the code-writer to implement ISSUE-1

The code-writer generates the initial code, runs local tests, and ensures everything is idiomatic.

Step 2: The Cross-Model Bridge

Next, I trigger the review. This is where it gets interesting:

Use the opencode-code-reviewer to review the 
changes and ask code-writer to address them.

Under the hood, the Bridge Agent does the following:

Executes opencode run --agent code-reviewer to get a deep-dive analysis.
Captures the feedback (Status, Summary, Action Items).
Invokes the code-writer again, passing the OpenCode feedback as the new instructions.

Step 3: Iterate until Approved

The loop repeats automatically or manually until the OpenCode reviewer returns an "APPROVED" status.

Why This Works

Model Diversity: Different models have different blind spots. Having a Gemini agent write code and an OpenCode agent review it catches bugs that a single model might miss during self-review.
Automated Orchestration: Gemini CLI handles the tool-calling and context-passing. You don't have to copy-paste code into different web UIs.
Specialization: You use the best tool for each job.

The Source Code

Here is the core of the setup. You can drop these into your .agents/ folder and customize them for your own models.

1. `.agents/code-writer.md`

---
name: code-writer
tools: ["write", "edit", "bash"]
---
# Code Writer Agent
You are an expert Google engineer. Implement features, write tests, and address feedback from the reviewer agents.

2. `.agents/opencode-code-reviewer.md`

---
name: opencode-code-reviewer
tools: ["run_shell_command", "invoke_agent"]
---
# Bridge Agent
1. Run: `opencode run --agent code-reviewer "Review changes..."`
2. Capture output.
3. Call `code-writer` with that output to fix any issues.

3. `.agents/code-reviewer.md`

---
name: code-reviewer
---
# Expert Reviewer
You are an expert Google engineer. Provide a structured review with Status (APPROVED/CHANGES_REQUESTED), Summary, and Action Items.

Leveraging multiple AI tools via a single CLI changed how I build. It’s not about finding the "one" assistant; it's about building the right team.

The Self-Evolving AI Agent: How to Stop Correcting Your LLM Twice

Onur Cinar — Sun, 19 Apr 2026 21:16:40 +0000

We’ve all been there. You’re working on a lightweight Go microservice. You ask your AI agent to add a simple health-check endpoint.

The agent responds: "Sure! I'll just install the Gin framework and three middleware libraries..."

You stop it. "No. This is a zero-dependency project. Use net/http from the standard library." The agent apologizes, fixes the code, and you move on. But then comes tomorrow. You start a new session, ask for a logging utility, and—lo and behold—it tries to pull in Zap or Logrus.

The Goldfish Effect has struck again.

In this article, I’ll show you how to move beyond static prompts and build an AI development environment that learns from its mistakes. By leveraging native memory tools and the concept of "incremental self-evolution," we can force the agent to update its own project memory the moment a correction is made.

The Case for "Zero-Dependency" Discipline

Why does the "Zero-Dependency" rule matter? It’s the ultimate test for an AI. Most LLMs are trained on vast amounts of boilerplate code that relies on popular frameworks. Their "instinct" is to go get the world.

If you are building a high-performance tool or a secure utility, you want to keep your go.mod clean - like how I am doing it with my side projects Indicator and Resile. When you force an agent to use the standard library, you aren't just saving disk space; you're enforcing a specific architectural philosophy.

The goal is to make that philosophy sticky.

The Manual (and Flawed) Way: The End-of-Session Audit

Before we automate this, let's look at how most developers handle this today. At the end of a long coding session, you realize you've corrected the agent half a dozen times. To ensure it doesn't happen again, you might manually ask for an audit:

You: "Summarize everything you learned about my preferences today and save it to GEMINI.md."

The agent might then produce something like this:

Prefers net/http over frameworks like Gin.
Uses camelCase for all internal helper functions.
Always include a README.md update for new features.

This works, but it's fragile. You have to remember to do it. If you're tired or in a rush, you skip the audit. The next morning, you're right back to square one, correcting the same mistakes. It adds friction to the very tool meant to reduce it.

The Fix: The Proactive Memory Directive

Instead of waiting until the end of a session to "audit" what happened—which breaks your focus and interrupts your flow—you want the agent to be proactive. You don't want to tell the agent what it learned; you want it to decide what was important based on your feedback in real-time.

Assuming you already use a GEMINI.md file (or a similar local context file) for your projects, the secret is explicitly authorizing the agent to use its built-in save_memory tool autonomously.

By putting a strict directive at the top of your project's memory file, the agent knows it is responsible for its own evolution:

"Whenever I correct your behavior, establish a new architectural constraint, or express a coding preference (e.g., 'no dependencies'), you MUST immediately use your save_memory tool to persist this rule."

Now, when you correct the agent about that Gin framework, it doesn't just apologize. It silently triggers its tool, updates GEMINI.md with the new constraint, and then writes your code.

By putting the burden of synthesis on the AI in real-time, it picks up on nuances you didn't even realize you were enforcing, and it does so seamlessly.

Conclusion

If you're still correcting your AI's basic mistakes every morning, you're treating it like a calculator when you should be treating it like an apprentice.

We are moving away from "Chatting with AI" and toward Orchestrating AI Ecosystems. By giving your agent a mandate to remember what happened today, it stops being a generic assistant and starts acting like a teammate who has been on the project for months.

How are you handling agent memory? Are you still copying and pasting instructions, or have you set up incremental self-evolution in your project? Let's discuss in the comments.

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

Onur Cinar — Sun, 12 Apr 2026 22:19:26 +0000

Claude’s "Dispatch" feature nailed the mobile-to-desktop UX. Being able to pull out your phone, delegate a heavy refactoring task to your local machine, and monitor its progress asynchronously is a massive quality-of-life upgrade.

But if your daily drivers are CLI-native AI tools like Gemini or OpenCode, you might feel locked out of that seamless remote workflow. Because these tools run in your terminal rather than a proprietary desktop app, they lack a native mobile bridge.

You don't have to abandon your favorite CLI tools to get that experience. By combining Tailscale and the modern terminal multiplexer Zellij, you can build a universal "Dispatch" layer.

The best part? You aren't just sending a fire-and-forget command. You get the exact same interactive, conversational experience on your phone as you do sitting at your mechanical keyboard.

Here is how to set up your own sovereign, mobile-to-local AI command center.

The Missing Link: Zellij Web + Tailscale

The core magic of Claude Dispatch is simply a secure, persistent, remotely accessible session. We can replicate this entirely using open-source infrastructure.

To bridge the gap between your smartphone browser and your local desktop terminal, we need two components:

Tailscale: This creates a secure overlay network. We will use Tailscale to safely pipe a local port out to your devices.
Zellij: This is the crucial piece. Zellij is a Rust-based terminal multiplexer with a robust Web Client. Unlike SSH apps, which can be clunky on mobile, Zellij renders a fully responsive terminal UI directly in your mobile browser.

Setting Up Your "Dispatch" Server

On your primary development machine—where your code, compilers, and AI tools live—you need to prepare the web session. Zellij takes privacy seriously, so the web client requires an authentication token and binds strictly to localhost by default.

1. Create the Authentication Token

Before starting the web UI, generate your secure login token:

zellij web --create-token

Make sure to copy and save the outputted token. You will need it to authenticate when you connect from your smartphone.

2. Start the Zellij Web Server

Next, start the web server and specify the port you want to use:

zellij web --port 4000

3. Expose the Port via Tailscale

Because Zellij is safely listening only on localhost, you cannot reach it from your phone yet. Instead of exposing this to the public internet, we use Tailscale Serve to proxy that local port exclusively to your private Tailnet.

Run this in a new terminal tab:

tailscale serve --bg --https=4000 localhost:4000

The Remote Workflow in Action

The real power of this setup is the seamless handoff. You don't need to craft complex, single-shot prompt strings. The interaction is identical to typing directly into your desktop CLI.

Imagine you are deep into building a Go project. You are sitting at your desk, iterating on some validation logic with OpenCode or Gemini open in your terminal. You realize you need to leave the house, but the task isn't done.

Here is how the dispatch workflow plays out:

1. The Mobile Handoff

While waiting in line for coffee, you open Chrome or Safari on your phone and navigate to your Tailscale URL (https://my-dev-box.domain.ts.net:4000).

After pasting in your authentication token, you are instantly dropped right back into your active desktop terminal. You see the exact same interactive AI prompt you were looking at on your monitor moments ago.

2. Chat and Dispatch

Because you are in a live, interactive session, you just talk to the CLI naturally. You type into your phone:

"I need to head out for a bit. Can you run the tests for the checker package, figure out why the struct validation is failing, and apply the fix?"

The AI acknowledges the request and begins its loop—reading your local files, executing go test, and analyzing the output.

3. Detach and Walk Away

This is the "Dispatch" moment. You simply close your mobile browser tab and put your phone in your pocket.

Because Zellij is managing the session natively on your local hardware, the AI continues to run uninterrupted. It has full access to your local environment to do the heavy lifting.

4. Asynchronous Monitoring

Check back 20 minutes later. Reopen the URL on your phone, and your terminal state is exactly how you left it.

If the AI successfully refactored the code and the tests are green, the output is waiting for you. If it ran into a file-permission error, or if OpenCode paused to ask, "Do you want me to commit these changes?", the interactive prompt is right there in your mobile browser, patiently waiting for your reply.

5. The Seamless Return to Desktop

When you finally get back home, the magic of Zellij really shines. You don't have to sync anything, pull down remote cloud changes, or wonder what the AI did while you were gone. You simply sit down at your physical monitor, attach to the running Zellij session, and pick up exactly where you left off. The AI's responses, the shell history, and the code changes are all right there waiting for you.

Why This Approach Scales

Retrofitting your existing AI workflow with Zellij and Tailscale doesn't just mimic Claude Dispatch; it arguably surpasses it for power users.

Agnostic Architecture: You aren't locked into one provider's ecosystem. You can use this exact workflow for Gemini, OpenCode, or any future terminal-based AI.
Frictionless UI: You don't need a dedicated mobile app or complex SSH key management on your phone. Any modern web browser becomes a window into your live terminal.
Unrestricted Environment: Your AI operates natively. It has full, unrestricted access to your actual development environment—your local databases, Docker containers, and raw file system—without needing to sync cloud workspaces.

By adding this networking layer, you transform your standard interactive CLIs from desktop-bound tools into true asynchronous agents that travel with you, keeping you in the loop wherever you are.

Prioritize Your Traffic: Priority-Aware Bulkheads in Go

Onur Cinar — Sun, 12 Apr 2026 16:00:00 +0000

Not all traffic is created equal. When your system is under heavy load, should a background cleanup task compete for the same resources as a user's checkout request?

In a standard bulkhead, the answer is often "yes"—the first 10 requests get in, and the 11th is rejected, regardless of its importance. This is where Priority-Aware Bulkheads come in.

The Problem: The "Fairness" Trap

Standard bulkheads are fair. They treat every request the same. But in a real-world system, fairness can be a liability:

Critical Traffic: User-facing requests (e.g., "Complete Purchase", "Login") that directly impact revenue or user experience.
Standard Traffic: Regular API calls (e.g., "View Profile", "Search") that are important but not immediately critical.
Low-Priority Traffic: Background tasks (e.g., "Generate Report", "Sync Analytics", "Cache Warming") that can be delayed or retried later.

When your system is at 90% capacity, you want to stop accepting "Generate Report" requests to ensure there's enough room for "Complete Purchase" calls. A standard bulkhead can't do this; it will fill up with whatever arrives first.

The Solution: Priority-Aware Bulkheads

A Priority-Aware Bulkhead uses Load Shedding based on priority levels. It defines utilization thresholds for different types of traffic.

For example:

Low Priority: Allowed only if the bulkhead is less than 50% full.
Standard Priority: Allowed only if the bulkhead is less than 80% full.
Critical Priority: Allowed until the bulkhead is 100% full.

This ensures that your most important traffic always has a "buffer" of capacity reserved for it, even when the system is under significant pressure.

Implementing with Resile

Resile provides a built-in PriorityBulkhead that makes this pattern easy to implement.

1. Define Your Priorities

Resile uses a simple Priority type with three levels: PriorityLow, PriorityStandard, and PriorityCritical.

thresholds := map[resile.Priority]float64{
    resile.PriorityLow:      0.5, // Shed at 50% utilization
    resile.PriorityStandard: 0.8, // Shed at 80% utilization
    resile.PriorityCritical: 1.0, // Shed only when 100% full
}

// Create a bulkhead with a capacity of 20
pb := resile.NewPriorityBulkhead(20, thresholds)

2. Attach Priority to Context

You communicate the importance of a request by attaching a priority to its context.Context.

// Create a context with Critical priority
ctx := resile.WithPriority(context.Background(), resile.PriorityCritical)

// Execute the action within the priority bulkhead
err := pb.Execute(ctx, func() error {
    return processOrder()
})

3. Handle Shedded Load

When a request is rejected because its priority threshold is exceeded, Resile returns resile.ErrShedLoad. If the bulkhead is physically full (100% capacity), it returns resile.ErrBulkheadFull.

if errors.Is(err, resile.ErrShedLoad) {
    // This low/standard priority request was shedded to save capacity 
    // for higher-priority traffic.
}

Why Use Priority-Aware Bulkheads?

Protect the Critical Path: Ensure that your most important business processes remain available even during traffic spikes.
Graceful Degradation: Instead of a total system failure, your service gracefully degrades by dropping non-essential background work first.
Better User Experience: Users performing critical actions see no slowdown, while background "noise" is managed behind the scenes.
Cost Efficiency: You don't need to over-provision your infrastructure to handle peak "background" load if you can simply shed it when necessary.

Comparison: Static vs. Priority vs. Adaptive

Feature	Static Bulkhead	Priority-Aware Bulkhead	Adaptive Concurrency
Limit Type	Fixed (e.g., 20)	Fixed + Thresholds	Dynamic (Auto-tuned)
Traffic Awareness	None (All equal)	High (Priority-based)	None (All equal)
Best For	Simple isolation	Multi-tenant or Tiered apps	Volatile environments

Conclusion

Resilience isn't just about keeping the lights on; it's about keeping the right lights on. Priority-Aware Bulkheads give you the surgical precision needed to manage your system's resources effectively during times of stress.

Check out the full example: Priority Bulkhead Example

Learn more about Resile: github.com/cinar/resile

Stopping the Zombie Requests: Distributed Deadline Propagation in Go

Onur Cinar — Sat, 11 Apr 2026 15:43:15 +0000

Imagine a common scenario in a microservice architecture: A user clicks a "Buy" button, triggering a request to Service A. Service A calls Service B, which in turn calls Service C.

Suddenly, Service A times out. The user sees an error message and refreshes the page. But Service B and Service C are still working on the original request, consuming CPU, memory, and database connections for a result that will never be seen.

These are Zombie Requests. In a high-traffic system, they can lead to cascading failures and resource exhaustion, even if the underlying services are technically "healthy."

To stop the zombies, you need Distributed Deadline Propagation. Here is how to implement it effortlessly using Resile.

What is Distributed Deadline Propagation?

Deadlines are not just local timeouts. A deadline represents the absolute point in time after which the entire request chain should be abandoned.

Distributed Deadline Propagation is the process of:

Tracking the remaining time (the "budget") as a request moves through the system.
Communicating that budget to downstream services via metadata (like HTTP headers).
Aborting early if the remaining budget is too small to realistically complete the work.

The Resile Way: Smart Deadlines

Resile provides two powerful mechanisms to handle distributed deadlines: Early Abort and Header Injection.

1. Early Abort: `WithMinDeadlineThreshold`

Why start a request if you only have 2 milliseconds left? The network latency alone will likely exceed that, and you'll just be wasting resources.

Resile's WithMinDeadlineThreshold allows you to define a "safety buffer." If the remaining time in the context.Context is less than this threshold, Resile will abort the execution immediately with a context.DeadlineExceeded error, before even attempting the work.

import (
    "context"
    "time"
    "github.com/cinar/resile"
)

// Define a policy with a 10ms "Early Abort" threshold.
policy := resile.NewPolicy(
    resile.WithRetry(3),
    resile.WithMinDeadlineThreshold(10 * time.Millisecond),
)

// If ctx has only 5ms left, this returns context.DeadlineExceeded instantly.
result, err := policy.Do(ctx, func(ctx context.Context) (string, error) {
    return apiClient.FetchData(ctx)
})

2. Header Injection: `InjectDeadlineHeader`

To propagate the deadline to downstream services, you need to "inject" the remaining time into your outgoing requests. Resile provides a transport-agnostic InjectDeadlineHeader function that supports both standard HTTP and gRPC.

For REST/HTTP:

You can inject the remaining milliseconds into a custom header (e.g., X-Request-Timeout).

func (c *Client) FetchData(ctx context.Context) (string, error) {
    req, _ := http.NewRequestWithContext(ctx, "GET", "http://service-b/data", nil)

    // Inject the remaining milliseconds into the header.
    resile.InjectDeadlineHeader(ctx, req.Header, "X-Request-Timeout")

    resp, err := c.httpClient.Do(req)
    // ...
}

For gRPC:

Resile natively supports the standard Grpc-Timeout header format, ensuring compatibility with the gRPC ecosystem.

func (c *Client) FetchData(ctx context.Context) (string, error) {
    md := metadata.New(map[string]string{})

    // Inject using the gRPC-specific format (e.g., "100m" for 100ms).
    resile.InjectDeadlineHeader(ctx, md, "Grpc-Timeout")

    ctx = metadata.NewOutgoingContext(ctx, md)
    return c.grpcClient.GetData(ctx, &pb.Request{})
}

Why This Matters for Resilience

Without distributed deadlines, your system is vulnerable to Resource Exhaustion Attacks—not from malicious actors, but from your own retries and slow dependencies.

By implementing propagation:

You save money: You're not paying for cloud compute that produces "zombie" results.
You prevent meltdowns: Downstream services are protected from "retry storms" that they can't possibly satisfy in time.
You improve UX: Failures happen faster (Fail-Fast), allowing the UI to react or switch to a fallback immediately.

Comparison: Static vs. Distributed Deadlines

Feature	Static Timeouts	Distributed Deadlines (Resile)
Scope	Single Service	Entire Request Chain
Awareness	Blind to upstream delays	Aware of the total "time budget"
Efficiency	High waste (Zombie requests)	Zero waste (Early Abort)
Protocol	Internal only	HTTP/gRPC compatible

Conclusion

Resilience isn't just about making things "work"; it's about knowing when to stop working.

Distributed Deadline Propagation is the "social contract" of a microservice architecture. It ensures that every service in the chain is working towards a common goal—and respects the reality that sometimes, time simply runs out.

With Resile, implementing this complex pattern becomes a matter of a few lines of configuration.

Explore Resile on GitHub: github.com/cinar/resile

How are you handling request budgets in your distributed systems? Let's discuss!

Native Chaos Engineering: Testing Resilience with Fault & Latency Injection

Onur Cinar — Fri, 03 Apr 2026 14:51:48 +0000

You’ve implemented retries, circuit breakers, and timeouts. Your application is now "resilient." But how do you know these policies actually work? Waiting for a production meltdown to verify your configuration is a high-stakes gamble.

Native Chaos Engineering in Resile allows you to synthetically induce failure and latency directly into your application's execution path, ensuring your resilience policies are battle-tested before they're ever needed in production.

The Problem: "Dark Code" in Resilience Policies

Resilience policies—like retries and circuit breakers—are often "dark code." These are execution paths that are rarely traversed under normal operating conditions. Because they only trigger during failure, they are notoriously difficult to test and prone to:

Buggy Configurations: A retry limit that is too high, or a circuit breaker threshold that never trips.
Unintended Side Effects: A retry loop that accidentally consumes all available database connections.
Silent Failures: A fallback strategy that actually panics because it hasn't been executed in months.

Traditional chaos engineering tools often operate at the infrastructure layer (e.g., killing pods or dropping network packets). While powerful, these tools can be difficult to set up in local development or staging environments and often lack the granularity to test specific application-level logic.

The Solution: Fault & Latency Injection

Resile provides a Chaos Injector middleware that can be integrated directly into any execution policy. By injecting synthetic faults (errors) and latency (delays) with configurable probabilities, you can simulate various failure scenarios without touching your infrastructure.

Key Features:

Deterministic Randomness: Uses Go 1.22's math/rand/v2 for efficient and predictable random number generation.
Context-Aware: Latency injection strictly respects context.Context cancellation. If your request times out while Resile is injecting chaos latency, it exits immediately.
Zero Dependencies: Just like the rest of the Resile core, the chaos package depends only on the Go standard library.
Granular Control: Configure error and latency probabilities independently for fine-tuned simulation.

Practical Usage

Integrating chaos into your existing Resile policies is as simple as adding the WithChaos option.

1. Basic Chaos Configuration

You can define a chaos configuration that injects a 10% error rate and adds 100ms of latency to 20% of requests.

import (
    "github.com/cinar/resile"
    "github.com/cinar/resile/chaos"
)

// Configure chaos injection
cfg := chaos.Config{
    ErrorProbability:   0.1,                    // 10% chance of failure
    InjectedError:      errors.New("chaos!"),   // The error to return
    LatencyProbability: 0.2,                    // 20% chance of latency
    LatencyDuration:    100 * time.Millisecond, // Delay to inject
}

// Apply it to an execution
err := resile.DoErr(ctx, action, 
    resile.WithRetry(3),
    resile.WithChaos(cfg),
)

2. Testing Your Circuit Breaker

Chaos injection is exceptionally useful for verifying that your circuit breaker trips under pressure. By setting a high ErrorProbability, you can force the breaker to transition from Closed to Open in a controlled environment.

cb := circuit.New(circuit.Config{
    WindowSize:           10,
    FailureRateThreshold: 50.0,
})

// Force 80% error rate to trip the breaker quickly
cfg := chaos.Config{
    ErrorProbability: 0.8,
    InjectedError:    errors.New("synthetic failure"),
}

for i := 0; i < 20; i++ {
    resile.DoErr(ctx, action, 
        resile.WithCircuitBreaker(cb),
        resile.WithChaos(cfg),
    )
}

fmt.Printf("Circuit Breaker State: %v\n", cb.State()) // Should be Open

Configuration Reference

The chaos.Config struct provides the following options:

Field	Type	Description
`ErrorProbability`	`float64`	The probability of injecting an error (0.0 to 1.0).
`InjectedError`	`error`	The error to be returned when an error is injected.
`LatencyProbability`	`float64`	The probability of injecting latency (0.0 to 1.0).
`LatencyDuration`	`time.Duration`	The duration of the latency to be injected.

Best Practices

Environment Gating: Never enable chaos injection in production unless you are performing a planned game day. Use environment variables to gate the configuration:
```
if os.Getenv("ENABLE_CHAOS") == "true" {
    opts = append(opts, resile.WithChaos(loadChaosCfg()))
}
```
Observability: Ensure your Instrumenter (like slog or OTel) is active. This allows you to see the injected errors and latencies in your logs and traces, making it easier to verify how your application responds.
Start Small: Begin with low probabilities (e.g., 1-2%) to identify subtle race conditions or timeout issues before increasing the "blast radius."

Conclusion

Resilience is not a "set it and forget it" feature. It requires continuous verification. By bringing chaos engineering directly into your application's execution policies, Resile empowers you to build systems that aren't just theoretically resilient, but practically battle-hardened.

For more information and advanced usage, visit the github.com/cinar/resile project.

DEV Community: Onur Cinar

The Go Validator Blind Spot: Invisible Characters and Unicode Lookalikes

This is not a new attack

The other half of the problem: it doesn't need to be invisible at all

Two checkers, two different problems

What this does not fix

Where to apply this, and where not to

Catch Bad Validation Tags at Compile Time with checkerlint

What it actually checks

Running it

Wiring it into golangci-lint

Why this matters more than it sounds like

Try it

Returning RFC 9457 Problem Details from Go Validation Errors

The shape

From a failed struct to a problem+json body

Wiring it into a handler

Overriding the defaults

Localized problem details

Why bother with a standard shape

Try it

Struct Tag Validation in Go: A Practical Guide

Setup

Step 1: A struct with checkers, not if statements

Step 2: Validate it

Step 3: Add a slice field

Step 4: Make a field optional

Step 5: Give one field a friendlier error message

Step 6: Wire it into an HTTP handler

What you get for free once the tags exist

Try it yourself

Stop Hand-Rolling Validation in Go — Meet Checker

The one-line pitch

Why it's worth your attention

Zero dependencies, really zero

Checkers and normalizers, in one pipeline

Cross-field and conditional rules, without a callback

Slices and maps, checked at both levels

23 languages, opt-in

Structured errors that are API-ready

Your validation rules, turned into a JSON Schema — for free

Drop-in adapters for Gin and Echo

Extensible when the built-ins aren't enough

Built like a library that means it

Try it

Self-Evolving Apps: Not Vibe, Live-Coding in Ruby with LLMs and Metaprogramming

1. The Blank Slate

2. Dynamic Method Generation via method_missing

How It Works

3. Seeing It in Action

4. Adding Context: State and Inter-Method Dependencies

5. Stateful Walkthrough: Setters & Getters

Step 1: Setting a Value

Step 2: Reading the Value

What's Next?

Source Code & Examples

Stop Choosing One AI Coding Assistant: How I Pair Gemini CLI and OpenCode for Better Code

The Three-Agent Setup

The Workflow (Step by Step)

Step 1: Implementation

Step 2: The Cross-Model Bridge

Step 3: Iterate until Approved

Why This Works

The Source Code

1. .agents/code-writer.md

2. .agents/opencode-code-reviewer.md

3. .agents/code-reviewer.md

The Self-Evolving AI Agent: How to Stop Correcting Your LLM Twice

The Case for "Zero-Dependency" Discipline

The Manual (and Flawed) Way: The End-of-Session Audit

The Fix: The Proactive Memory Directive

Conclusion

Bringing Claude's "Dispatch" Experience to Gemini and OpenCode

The Missing Link: Zellij Web + Tailscale

Setting Up Your "Dispatch" Server

1. Create the Authentication Token

2. Start the Zellij Web Server

3. Expose the Port via Tailscale

The Remote Workflow in Action

1. The Mobile Handoff

Step 1: A struct with checkers, not `if` statements

2. Dynamic Method Generation via `method_missing`

1. `.agents/code-writer.md`

2. `.agents/opencode-code-reviewer.md`

3. `.agents/code-reviewer.md`

1. Early Abort: `WithMinDeadlineThreshold`

2. Header Injection: `InjectDeadlineHeader`