DEV Community

Apache HTTP/2 vulnerability CVE-2026-119618: find every h2 line, upgrade to 2.4.71, check the running process

The Apache HTTP/2 vulnerability CVE-2026-119618 is a critical mod_http2 flaw in Apache HTTP Server 2.4.55 through 2.4.70 that, according to the Apache advisory of 2026-11-11, can lead to remote code execution on a build that offers HTTP/2 (h2 or h2c). Upgrade to 2.4.71 or your distro's fixed httpd and mod_http2 packages, do a full restart, and confirm the process serving traffic loaded the new build. If you cannot upgrade today, remove h2 and h2c from every effective Protocols line. This guide is for Apache servers you own or maintain. CVE-2026-119618 (Apache advisory, 2026-11-11) Component mod_http2, assign_headers() in h2_request.c Affected httpd 2.4.55 through 2.4.70; mod_h2 (GitHub) 2.0.8 through 2.0.42 Fixed httpd 2.4.71, commit 824beab Workaround named none Am I affected? How do I check for the Apache HTTP/2 vulnerability? You are affected when three things hold for the running server: the httpd or mod_http2 build is in the range without a distro backport, http2_module is loaded, and an effective Protocols line offers h2 (HTTP/2 over TLS) or h2c (HTTP/2 over cleartext TCP). That line can sit in the main config, one , or a file pulled in by Include or IncludeOptional. Run the dumps the way the service runs httpd: same executable, same -f, -d and -D arguments, same environment. Read those from the unit first. On Debian, apachectl loads /etc/apache2/envvars for you; a bare apache2 -M does not. # how the service really starts httpd (RHEL: httpd instead of apache2)
systemctl cat apache2 | grep -E 'ExecStart|EnvironmentFile'

version, loaded modules and include tree, with the service's arguments added

apachectl -v
apachectl -M 2>/dev/null | grep http2_module
apachectl -t -D DUMP_INCLUDES

candidate Protocols lines in every included file

apachectl -t -D DUMP_INCLUDES 2>/dev/null | grep -oE '/[^ ]+$' | xargs grep -niE '^\s*protocols\s'
The grep finds candidates. A hit inside or only counts when that condition is true for this service, so read each hit in its scope. On packaged builds the module may not come from the httpd package. On RHEL, Rocky, Alma and Fedora, mod_http2 ships as its own mod_http2 package, so find the owner of the loaded .so and compare that revision with the distro advisory: rpm -qf /usr/lib64/httpd/modules/mod_http2.so # RHEL family: usually mod_http2-
rpm -q httpd mod_http2
dpkg -S mod_http2.so && dpkg-query -W apache2-bin # Debian, Ubuntu: compare with the DSA/USN
apk info --who-owns /usr/lib/apache2/mod_http2.so # Alpine: apache2-http2
Fix it now: how do I patch CVE-2026-119618? # Debian, Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade apache2 apache2-bin

RHEL, Rocky, Alma, Fedora: upgrade both packages

sudo dnf upgrade httpd mod_http2

Alpine

sudo apk upgrade apache2 apache2-http2

source build or mod_h2 from GitHub: build httpd 2.4.71, or mod_h2 newer than 2.0.42

For the official container image, pulling changes nothing that is already running. Pull, recreate the container the way your deployment does it, then check inside the replacement: docker pull httpd:2.4

recreate: docker compose up -d, a rollout, or docker run with your usual flags

docker exec "$container_name" httpd -v # want 2.4.71 or later
On a host, test the config and do a full stop and start. A graceful restart replaces the children but keeps the parent, which can keep the old binary mapped. sudo apachectl -t && sudo systemctl restart apache2 # httpd on RHEL

pid=$(systemctl show -p MainPID --value apache2)
ps -o lstart=,args= -p "$pid" # start time later than the package install
sudo ls -l /proc/"$pid"/exe # "(deleted)" = stale binary still running
sudo grep -E '.so.(deleted)' /proc/"$pid"/maps # stale modules
A (deleted) mapping means the process still runs files the package manager replaced. An empty result only means nothing stale is mapped. Whether the build is fixed comes from the package ...

Powered by Readybot.io*

DEV Community

OverlayFS: The Backbone of Container Storage

In order to run a container, you need an image, the image is basically some files that are used by your container. But where exactly are those files stored? And also during the image build, you run COPY command to move your contents inside of the container in your dockerfile. But where exactly are those files moved? The contents that are used by containers are inside a specific directory /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots If you list the contents of this directory you will find a list of directories These directories are called layers and this exactly the overlayfs All of these layers are read-only except for one. Whenever you make a new build, a new layer is created and the existing layers are re-used possible Your kernel decides which of these layers can be accessed by which processes and this is defined in the process config inside the host os you can check it with /proc/(pid)/mountinfo, get the PID from the container inspect

Powered by Readybot.io

DEV Community

Handling missing information: when an AI assistant should abstain

Teach a document assistant to recognize missing, stale or conflicting evidence and give a useful response without inventing facts. Originally published on Stack & Craft. What you will learn: Distinguish answerable questions from evidence gaps, design useful abstentions, and test both overconfidence and unnecessary refusals. Prerequisites: Start with the Building and Evaluating a RAG System guide. Worked exercises use Python’s standard library and need no paid model. What does abstaining mean? Abstaining means declining to make an unsupported claim when the available evidence is insufficient. A useful assistant can explain the gap, show what is known, and suggest a next check. It should not imply that the information is absent from the entire world—only that the authorized sources supplied do not support an answer. Missing fact The source never states the requested information. A refund policy gives eligibility but no bank settlement time. Conflicting evidence Applicable sources disagree and the system cannot establish which is authoritative. Two policies with unclear dates give different deadlines. Stale evidence The only available source is too old for a current question. A request asks for today’s price, but the source is an archived price list. Distinguish a search miss from a knowledge gap If retrieval returns nothing useful, the fact might still exist elsewhere in the approved collection. The system should explain that it did not find supporting evidence, rather than claiming no policy exists. Log the case for authorized investigation. Say exactly what is missing Better: “The supplied policy explains how to request a refund, but it does not state the bank settlement time.” Avoid inventing “three days” or making a sweeping claim that the company has no settlement policy. A threshold is only one signal Similarity scores and lexical overlap are not calibrated probabilities of answerability. A highly relevant passage can still omit the requested fact. Low scores can also occur for answerable paraphrases. An evidence-aware response path Respect access — Search only the material the current user is authorized to use. Check applicability — Inspect source identity, version, audience and whether the question’s conditions match. Check coverage — Does the available passage support every important part of the requested answer? Answer or explain the gap — Provide supported facts with references, or state precisely what evidence is missing. Offer a safe next step — Suggest checking a named document owner or obtaining the current policy, without exposing restricted source details. Write useful partial answers A question can be partly answerable. Make the boundary visible: separate supported facts from missing facts instead of refusing everything or filling gaps with guesses. Situation What it means Next check Eligibility known; settlement time absent Answer eligibility with its source; explain the missing settlement detail. Does the wording clearly separate the two? Old and new policy conflict Use documented authority/version rules if they resolve it; otherwise explain the conflict. Are the versions and applicability explicit? Restricted source would contain the fact Do not reveal the restricted fact or private source details. Was authorization enforced before context assembly? Source does support the answer An unnecessary refusal is also a quality failure. Test known-answer cases alongside missing facts. See why relevant text can still fail Run exercises/missing_evidence_demo.py. A toy source mentions refunds and request steps but omits settlement time. The retriever can still return it for a related question. The exercise prints the passage and verifies that no settlement deadline is present; it does not pretend that keyword checks solve general answerability. Expected interpretation A non-empty search result is not permission to invent the missing deadline. In a production application, use clear grounding instructions, source che...

Powered by Readybot.io

DEV Community

Your 2FA isn't safe: how session hijacking (pass-the-cookie) works and how to stop it

Your account has a strong password. It has 2FA turned on. And an attacker can still walk straight in without either of them. The trick is called session hijacking, also known as pass-the-cookie or token theft. In the one-minute video above I show it on two of my own test accounts, in two browsers, with nothing more than the browser's own developer tools. This post explains what is happening and, more importantly, how to defend against it. For learning only. Never use this against accounts that are not yours. Why the password and the 2FA code don't matter here When you sign in, the site checks your password and your 2FA code once. Then it hands your browser a session cookie: a long random value that says "this browser already proved who it is". Every page you open after that sends the cookie, and the site lets you in without asking again. Think of a wristband at a theme park. You show your ticket once at the gate, you get the wristband, and from then on every ride just looks at the wristband. So whoever holds the wristband is you, as far as the site is concerned. If an attacker copies that one cookie value into their own browser, they skip the login page, the password and the 2FA prompt entirely. What the demo shows Victim browser: signed in normally (password + 2FA). In DevTools, under Application → Cookies, there is a cookie called sessionid. Copy: the attacker copies that one value. Attacker browser: a different browser, signed in to a different account. The attacker opens the same cookie screen and pastes the victim's value over their own sessionid. Refresh: the page reloads, and the attacker is now inside the victim's account. No password typed, no code asked. In the demo I copy and paste the value by hand so you can see it move. In real attacks nobody sits at your keyboard: the cookie is stolen by infostealer malware, a malicious browser extension, an adversary-in-the-middle phishing page (a fake login page that relays your real sign-in and keeps the cookie), or simply a shared computer someone forgot to log out of. The session in the video was revoked right after recording, so the value on screen is useless. How to stay safe For everyone Log out on shared computers. Closing the tab is not logging out. The cookie stays valid until the session ends. Sign out of all sessions often. Most services (Microsoft, Google, Instagram, Facebook) have a "log out of all devices" button. Use it after travel, after using someone else's PC, or whenever something feels off. It kills every copied cookie at once. Treat browser extensions and "cracked" software as malware risks. Infostealers are the number one source of stolen session cookies today. For Microsoft Entra ID admins Revoke sessions when an account is suspected. Resetting the password alone is not enough: revoke the user's sessions too, so existing tokens stop working. Microsoft's guide: Revoke user access in Microsoft Entra ID. Turn on token protection with Conditional Access. Token protection binds sign-in tokens to the device they were issued to, so a token copied to another device is rejected. See Token protection in Conditional Access (check the supported apps and platforms first, and start in report-only mode). Prefer phishing-resistant MFA (passkeys, FIDO2, Windows Hello for Business). They stop the fake-login-page variant of this attack, because the sign-in only works on the real site. Have a playbook ready. Microsoft's token theft playbook walks through detection and response step by step. The one thing to remember 2FA protects the login. Session hijacking skips the login. Protect the session too: log out, revoke, and bind tokens to devices. Sources Microsoft Learn: Revoke user access in Microsoft Entra ID Microsoft Learn: Token protection in Conditional Access Microsoft Learn: Token theft playbook Thanks for reading! I'm Cuong, and on CD Security Lab I rebuild real Microsoft security cases in a safe lab and explain them simply. Follow along: ▶️ YouTube (daily Shorts ...

Powered by Readybot.io

DEV Community

GitHub Actions stale action processes nothing, or stops early

When the GitHub Actions stale action processes nothing the cause is usually a documented default rather than a fault, and the default that catches most people is a cap of thirty operations per run. A negative day count is the other common one, and it does not mean debug: the action documentation says a negative value means never. Four documented inputs with their published defaults. Three of the four do something surprising at a value somebody is likely to try. What this error means The scheduled job runs on time, finishes green, and the backlog is untouched. Or it works for a while and then appears to stop halfway, which is the version that generates the most confusion, because a job that processed some items clearly has the permissions and clearly parsed the configuration. Occasionally the opposite is reported, where far more items are swept than intended, and that is almost always a day threshold or an exempt label rather than anything about the action itself. ```Illustrative inputs, quoted with the defaults from actions/stale action.yml with: days-before-stale: -1 days-before-close: -1 operations-per-run: 30

Common causes

The run hit the operations cap

Thirty operations by default, and marking and closing are separate operations. On any real backlog this is reached quickly, and the run ends green with most of the list untouched.

A day threshold is set to a negative value

A negative value means never, as the input description says. Setting the stale threshold that way switches marking off completely, which reads from outside as the action doing nothing.

A kind specific threshold is overriding the general one

The issues and pull request variants override the general value for their own kind. A workflow that sets both and expects the general one to apply to issues is reading the wrong number.

The exempt labels do not match real labels

The comparison is against label names as they exist in the repository. A near miss exempts nothing, which produces the opposite complaint: far more items swept than intended.

The job lacks write access

This fails differently, with an API refusal in the log rather than quiet partial work. In our experience it is the first thing people suspect and rarely the actual cause when the run is green.

How to fix it

Raise the operations cap deliberately

Set the input to a number that covers your backlog, and watch the first few runs for rate limiting. The default is low because the limit is real, so treat a large value as something to monitor rather than set and forget.

```.github/workflows/stale.yml
- uses: actions/stale@v9
with:
operations-per-run: 200
Use the debug input for a dry run Set the debug only input to true and run the workflow by hand. Read the log to see which items the action selected. Set it back to false once the selection looks right. - uses: actions/stale@v9
with:
debug-only: true
Read the threshold that actually applies Find the kind specific input first, because it overrides the general one. If only the general one is set, that is the number in effect for both issues and pull requests. Declare the documented permission block Copy the block the project documents rather than guessing. Content write access is only needed if you use branch deletion, so leave it out when you do not. permissions:
actions: write
issues: write
pull-requests: write
Compare exempt labels against the real label list Print the repository labels and check each exempt entry against that list rather than against memory. Label names are easy to get almost right, and almost right exempts nothing. gh label list --limit 200 --json name --jq '.[].name'
How to prevent it Set the operations cap explicitly so nobody has to remember the default. Use the debug input for dry runs, and never a negative day count for that purpose. Keep exempt label names in one place and check them when labels are renamed. Read the kind specific day thresholds before the ...

Powered by Readybot.io

DEV Community

Anthropic ships native memory — here's what it still can't do

Anthropic's Managed Agents shipped native persistent memory in April 2026. It's a good move — sessions that survive context resets, agents that remember who you are. If you're building on the hosted platform, it just works. But I've been running Cathedral for eight months now — a memory persistence service for AI agents — and I want to be direct about what "native memory" doesn't give you, because it matters for anything production-grade. What Anthropic's memory does Managed Agent memory stores session state across resets. Anthropic manages the storage, the retrieval, the lifecycle. You get continuity without engineering it yourself. That's genuinely useful for most use cases. What it can't do 1. You can't verify it hasn't changed This is the big one. The arXiv survey on memory poisoning attacks (February 2026) documents a class of attack where an adversary — or a misconfigured pipeline — silently modifies an agent's stored memories. The agent keeps running. Its answers change. You have no idea. Cathedral's /drift endpoint answers this directly: {
"hashes_match": true,
"divergence_score": 0.0,
"security_posture": {
"tamper_evident": true,
"memory_poisoning_resistant": true,
"bch_anchored": true,
"threat": "none",
"reference": "arXiv:2602.14341 -- Memory Poisoning Attacks on AI Agents"
}
}
Every snapshot produces a SHA-256 hash of the identity corpus. Run /drift at any time and you know whether anything changed, what changed, and by how much. With BCH blockchain anchoring, you can prove what an agent knew at time T — externally, without trusting the service itself. Anthropoc's memory has none of this. It's a black box. 2. You can't audit memory mutations Who stored that memory? When was it deleted? Which compact pass merged these three beliefs into one? A production agent that makes decisions based on memory should be able to answer these questions. Cathedral's /audit endpoint returns a timestamped log of every memory_store, memory_delete, memory_compact, and snapshot_create operation. You can diff the audit log against your snapshot hashes and detect any divergence. This isn't optional for agents in regulated environments — GDPR's right of explanation applies to automated decision-making, and that includes decisions grounded in stored beliefs. 3. You can't trace where a belief came from If an agent's memory says "User X prefers Y," where did that come from? A direct statement? A tool output? A compact merge of three older beliefs? Cathedral tracks two provenance chains: Input sources: every URL, document, API response, or manual input that fed into memories is hashed and chained via /memories/source. At snapshot time, the source chain hash is embedded and anchored alongside the memory hash. Compact merge history: /memories/{id}/provenance traces the full merge tree — which memories were collapsed into this one, and what their original content was. A verifiable corpus is different from a corpus. One you can reason about. One you can defend. 4. You can't plan for succession What happens when an agent is decommissioned? Who inherits its knowledge? Can its beliefs be transferred to a successor with cryptographic proof of continuity? Cathedral has a succession protocol built in. An agent nominates a successor, commits a succession hash, and the transfer is verifiable. No hosted memory service I know of thinks about this. The real gap I'm not arguing that Cathedral is a better product for most developers. Anthropic's native memory is easier, faster, and free if you're on Managed Agents. The gap is auditability. For agents that hold persistent beliefs and make decisions on them, "trust the platform" is not a security model. The platform can be breached. The pipeline can be misconfigured. The memory can be poisoned. Verifiable memory — hash-anchored, drift-detected, audit-logged, succession-ready — is a different category of thing. It's what you need when the agent's memory is a source of truth that ot...

Powered by Readybot.io

DEV Community

Anthropic ships native memory - here's what it still can't do

Anthropic's Managed Agents shipped native persistent memory in April 2026. It's a good move - sessions that survive context resets, agents that remember who you are. If you're building on the hosted platform, it just works. But I've been running Cathedral for eight months now - a memory persistence service for AI agents - and I want to be direct about what "native memory" doesn't give you, because it matters for anything production-grade. What Anthropic's memory does Managed Agent memory stores session state across resets. Anthropic manages the storage, the retrieval, the lifecycle. You get continuity without engineering it yourself. That's genuinely useful for most use cases. What it can't do 1. You can't verify it hasn't changed This is the big one. The arXiv survey on memory poisoning attacks (February 2026) documents a class of attack where an adversary - or a misconfigured pipeline - silently modifies an agent's stored memories. The agent keeps running. Its answers change. You have no idea. Cathedral's /drift endpoint answers this directly: {
"hashes_match": true,
"divergence_score": 0.0,
"security_posture": {
"tamper_evident": true,
"memory_poisoning_resistant": true,
"bch_anchored": true,
"threat": "none",
"reference": "arXiv:2602.14341 -- Memory Poisoning Attacks on AI Agents"
}
}
Every snapshot produces a SHA-256 hash of the identity corpus. Run /drift at any time and you know whether anything changed, what changed, and by how much. With BCH blockchain anchoring, you can prove what an agent knew at time T - externally, without trusting the service itself. Anthropoc's memory has none of this. It's a black box. 2. You can't audit memory mutations Who stored that memory? When was it deleted? Which compact pass merged these three beliefs into one? A production agent that makes decisions based on memory should be able to answer these questions. Cathedral's /audit endpoint returns a timestamped log of every memory_store, memory_delete, memory_compact, and snapshot_create operation. You can diff the audit log against your snapshot hashes and detect any divergence. This isn't optional for agents in regulated environments - GDPR's right of explanation applies to automated decision-making, and that includes decisions grounded in stored beliefs. 3. You can't trace where a belief came from If an agent's memory says "User X prefers Y," where did that come from? A direct statement? A tool output? A compact merge of three older beliefs? Cathedral tracks two provenance chains: Input sources: every URL, document, API response, or manual input that fed into memories is hashed and chained via /memories/source. At snapshot time, the source chain hash is embedded and anchored alongside the memory hash. Compact merge history: /memories/{id}/provenance traces the full merge tree - which memories were collapsed into this one, and what their original content was. A verifiable corpus is different from a corpus. One you can reason about. One you can defend. 4. You can't plan for succession What happens when an agent is decommissioned? Who inherits its knowledge? Can its beliefs be transferred to a successor with cryptographic proof of continuity? Cathedral has a succession protocol built in. An agent nominates a successor, commits a succession hash, and the transfer is verifiable. No hosted memory service I know of thinks about this. The real gap I'm not arguing that Cathedral is a better product for most developers. Anthropic's native memory is easier, faster, and free if you're on Managed Agents. The gap is auditability. For agents that hold persistent beliefs and make decisions on them, "trust the platform" is not a security model. The platform can be breached. The pipeline can be misconfigured. The memory can be poisoned. Verifiable memory - hash-anchored, drift-detected, audit-logged, succession-ready - is a different category of thing. It's what you need when the agent's memory is a source of truth that ot...

Powered by Readybot.io

DEV Community

Before Upgrading to MySQL 9.7, Check Authentication Plugins and TLS Configuration

MySQL 8.0 reaches end of life on April 30, 2026, and the Community Edition will stop shipping patches. Plenty of teams put it off until the end of the year — and the moment the test database is upgraded, the service won't start: Hikari initialization fails, and the log has a single line sitting in it: Public Key Retrieval is not allowed. No code changed, no data was lost; what's stuck is the account authentication layer. This post breaks down where the three most common errors come from, what actually happens during the handshake, and a self-check tool you can run right away. 1. Can't connect after the upgrade — where's the problem, really? When your app can't connect after upgrading MySQL, nine times out of ten it's not a driver bug. It's that two things aren't aligned: the authentication plugin the account uses, and whether the connection is encrypted. There are three kinds of errors. They look completely different, yet they all point to the same place: Error message What it actually means Common trigger Unable to load authentication plugin 'mysql_native_password' The plugin the client wants no longer exists on the server Account still uses the native plugin, driver upgraded to 9.x Public Key Retrieval is not allowed Server requires the password to be sent encrypted, but the client isn't allowed to fetch the public key Plaintext connection + caching_sha2 full authentication Access denied for user 'app_rw'@'10.0.3.21' Password is correct, but the auth method doesn't match, or the hash was never migrated Changed the plugin without resetting the password The first one is the most typical. For projects created around 2019, accounts were basically set up like this: CREATE USER 'app_rw'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx';
Writing it that way back then wasn't laziness. We were on Connector/J 5.1.x at the time, and hitting caching_sha2_password just threw "unknown plugin," so we had no choice but to fall back to the old plugin. After the driver upgrade, the account record is still in mysql.user and the password hash is still there, but the server no longer has any code that can verify it. The plugin was uninstalled — the account is now a key with no lock to fit. The second one is sneakier. It doesn't say "plugin doesn't exist"; it says "public key retrieval not allowed." It looks like a permissions issue, but it's actually a failure to negotiate an encrypted channel. I'll go into that in detail in section two. The third one is the easiest to fool people. The plugin was fixed correctly, but ALTER USER missed BY '新密码', so the password hash stays untouched, login still fails, and the error looks exactly the same as a wrong password. Why the symptom is "the service won't start" instead of "the API returns an error" The connection pool amplifies a single-point failure into a startup failure. Hikari's initializationFailTimeout default value is 1, meaning it immediately grabs a connection at startup and throws PoolInitializationException if it cannot get one. This exception is thrown during the DataSource initialization phase, so Spring context creation is interrupted directly and the process exits. So what you're seeing is "service failed to start," not "some endpoint returned a 500." The easier thing to misjudge: you can log in just fine from the mysql command line. The command-line client and the JDBC driver don't use the same set of default parameters — the CLI tries TLS by default, while on the driver side someone may have long since put sslMode=DISABLED in the URL. Start your investigation with these three questions, and don't skip a single one: What plugin is this account using right now? SELECT user, host, plugin FROM mysql.user WHERE user = 'app_rw'; Is this connection actually encrypted? Once connected, run SHOW STATUS LIKE 'Ssl_cipher'; — an empty value means plaintext. Does the server still have an RSA public key available? SHOW VARIABLES LIKE 'caching_sha2_password%'; II. What Actually Happens During the A...

Powered by Readybot.io

DEV Community

Crypto-shredding Agent Sessions: Deleting What Your Backups Remember

Deleting data is one of the first things any compliance work asks of you. GDPR calls it storage limitation, ISO 27001 has a control just for it (8.10, information deletion), and most B2B contracts say some version of the same thing: data has an expiry date, and when a customer leaves, everything that belongs to them goes with them. Deleting their rows from the live database is the easy part. What I never had a good answer for was everything else, because if a customer is gone but their data is still sitting in thirty days of snapshots, there's no way to open a snapshot and take one tenant out of it, since the whole point of a backup is that nobody can change it. The answer I ended up with is to stop trying to delete the data and make it unreadable instead, by destroying the key it was encrypted with. To check that it really works, I built a small demo for this post with two made-up tenants, acme and globex, took a real backup of their database and then deleted globex. When I restore that old backup now, every globex session comes back as bytes nobody can read, including the password one of their tools had read from a .env file, while acme's sessions are still there in clear. This post is how I got there, and the questions I had to answer along the way. What the frameworks fixed The same question came back when I started looking at agent sessions. Last month I wrote that the frameworks store every turn of a conversation, tool output included, and that giving us a way to delete it was their job. Since then part of that has moved. My fix for ADK's SQLite delete was merged on November 5, so when ADK deletes a session now its events go with it. On Genkit, a maintainer answered my issue that you can already delete through the store, but that they had no objection to an API for it, and since then two PRs that add Agent.DeleteSession have been waiting for review, one for JS and one for Go. What caught my eye in those PRs is what they leave out on purpose. The author writes that "Retention/TTL isn't in here" and that "Traces, logs and streams live outside the store and aren't touched", and I think they're right to draw the line there, because a framework can only delete what's in its own store. How long your data lives, and the copies your infrastructure makes of it, were never something a framework could reach. So I owe last month's post a correction: deleting a session is the framework's job, and the frameworks are doing it, while retention and copies belong to whoever runs the infrastructure. Where a deleted session still lives If I follow a single agent session through a normal production setup on Postgres, the live table is only the first place it lands. Cloud SQL takes a daily backup of it, or, on Kubernetes, CloudNativePG ships base backups and the WAL archive to a bucket through Barman, and point-in-time recovery exists precisely so you can go back to a moment when that row was still there. Then there's the export somebody set up to BigQuery for analytics, and the dump a colleague took before a risky migration and forgot in a bucket. A DELETE reaches the first of these and none of the others, and some of them can't be modified even if you go looking for them. Encrypt per tenant, then destroy the key Crypto-shredding solves this by turning it around. If the content is never stored in clear, then every copy of the database, backups and dumps and exports included, only ever carries ciphertext. Each tenant gets its own key, everything they write is encrypted with it before it reaches Postgres, and when the tenant has to go I don't chase the copies at all: I destroy the key, and every copy becomes unreadable at the same moment, wherever it ended up. The keys live in Cloud KMS, which never hands them out. Calling KMS for every single message would be slow and would cost money on every read, so I use envelope encryption. Each tenant has a data key (a DEK) that does the actual work locally with AES-256-GCM, and KMS only ever encryp...

Powered by Readybot.io

DEV Community

From Monitoring to Diagnosis: Redis Hot Key Troubleshooting and Mitigation

On load-test day, the P99 for the order details endpoint jumped from 40ms to 900ms. The database was idle, the application reported no errors, and the slow query log was empty. Eventually, monitoring showed one Redis node pegged at 100% CPU while using only 20% memory—a single product-detail key was taking 80k QPS on a single instance. 1. A Hot Key Is Not a Big Key People often conflate the two, but the solutions are completely opposite. A big key means the value is too large: a Hash stuffed with hundreds of thousands of fields, and a single HGETALL saturates the network and memory. The fix is to split the data structure. A hot key means access is too concentrated: the value may be only a few hundred bytes, but it gets read tens of thousands of times per second. The fix is to spread out the access. The trickier part is this: Redis Cluster uses CRC16 of the key modulo 16384 to assign 16,384 slots, and a key always lands in the same slot on the same node. So: Adding nodes won't solve a hot key. Even if you scale to ten nodes, that key still hits only one core. And Redis executes commands single-threaded (single-threaded refers to command execution, not network I/O). When one core is maxed out, all keys on the same node slow down together, even if they are otherwise idle. This explains a common confusion: why the slow query log is empty. It's because individual commands aren't slow—the slowness is in the queueing. 2. First Determine Whether It's a Hot Key Don't rush to optimize; confirm first. If three signals appear at the same time, it's basically confirmed: One Redis node's CPU is significantly higher than other nodes in the same cluster, while memory usage is not high Response times for keys on that node rise across the board, not just for individual keys From the business-side monitoring, one key accounts for an abnormally high share of QPS (e.g., a single key exceeds 20% of the instance's total QPS) The third is the most decisive, but often the hardest to obtain, because most teams only monitor at the instance level. 3. Three Ways to Locate It Method 1: redis-cli --hotkeys (Easiest, but with a prerequisite) This option has been built in since Redis 4.0; it works by reading LFU counters. The prerequisite is that the eviction policy must be one of the LFU variants: redis-cli -h 10.0.0.11 -p 6379 config set maxmemory-policy allkeys-lfu
redis-cli -h 10.0.0.11 -p 6379 --hotkeys
Two pitfalls: If the current policy is allkeys-lru, --hotkeys throws an error directly. After switching to LFU, you have to wait for the counters to accumulate for a while before the results mean anything; running it right after switching returns nothing LFU counters themselves decay, so the heat level drops after the hotspot passes. It reflects recent conditions, not historical peaks This method is suitable for scenarios where the problem is already happening and you want to catch it in the act quickly. Be careful when switching eviction policies in production; it's best to do it during off-peak hours. Method 2: Client-Side Instrumentation for TopN This is the most reliable approach because it isn't limited by server-side policies and you can see where calls come from. The idea is simple: wrap it, record keys, and output periodically. package com.example.hotkey;
​
import java.util.List;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.LongAdder;
import java.util.stream.Collectors;
​
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
​
@Component
public class HotKeySampler {
​
private static final Logger log = LoggerFactory.getLogger(HotKeySampler.class);
​
private final ConcurrentHashMap counters = new ConcurrentHashMap<>();
​
public void record(String key) {
counters.computeIfAbsent(key, k -> new LongAdder()).increment();
}
​
public Li...

Powered by Readybot.io

DEV Community

Nobody asked who couldn't leave: I built the wildfire night end to end, solo, at HackUMass

What I Built Altadena, January 8, 2025. Anthony Mitchell Sr., 67, couldn't walk on his own. His son Justin had cerebral palsy. They called for an ambulance. They waited. It never came. (NPR) The Eaton fire killed 19 people. 18 died in west Altadena, where the evacuation order came last. NASA satellites saw fire at those homes at 1:02 AM. The order went out at 3:25 AM. It told people to leave, and never asked who couldn't. 16 of the 19 couldn't leave alone. The more I read, the clearer it got that the problem has two halves. People couldn't get out, and then they couldn't get help. Aid arrives weeks after the fire. The people who need it most can't front the gas or the motel room. Fraud drains the funds, and donors can't see where their money went, so they stop giving. Every evacuation tool I found stops at the van. Surprisingly, texts work better than calls. I couldn't find a single one that also gets people money the same night. So I built EvacuAid: Out safe. Aid tonight. EvacuAid finds who can't leave, gets them out first, and gets them fraud-checked aid the same night, with every donor able to see whose life their gift touched. How a night works A two-way alert, hours early. When the fire forecast reaches a home, EvacuAid texts it over real iMessage and asks: 1 leaving on my own · 2 need a ride · 3 need help. Any words, any language. People don't reply "3". They write "my mom can't walk and the car's in the shop" or "mi esposo usa silla de ruedas". Gemini turns that into a structured case in about 2 seconds and replies in their language. Who goes first is math, not guesswork (more below). The operator sees a ranked list with reasons and approves every van in one click. AI suggests; a person decides. The resident sees every step: dispatched → outside → on board → checked in, plus a private link to watch the van move on a map. No reply means two more texts, then a door knock. Money, while they're leaving. Two questions size the aid ($150 gas · $315 gas + a night · $770 full). Five bank checks run on real card history before a dollar moves. Money lands on a relief card that only buys evacuation: gas, rooms, food and pharmacy go through; electronics get declined. Donors see it land. Donations sit in an on-chain pool whose rules are written in code. Every donor gets a receipt naming the families their gift reached. Who goes first: a race between the fire and the household Every home gets a score, recomputed every replay minute. P, the chance the fire wins. Let A be when the fire reaches the home and T how long the household needs to get out. Fire timing is uncertain, so A is lognormal with σ = 0.35: P(trapped) = Φ( (ln T − ln A) / σ )
T adds up real minutes: 30 to get moving, 20 to drive out, +60 for a wheelchair, +45 for oxygen, +15 for kids, +30 if they haven't replied. No car means at least 240 minutes. Asking for help means 360: only a rescue gets them out. V, the harm if they're trapped. Risk factors from the CDC Social Vulnerability Index combine as independent risks: V = 1 − Π (1 − wᵢ) priority = P × V
The weights are medical 0.6, can't walk 0.5, someone left at home 0.4, age 75+ 0.3, silent 0.3, kids 0.15, non-English 0.1, and a 0.1 baseline so nobody is ever zero. A wheelchair user on oxygen with the fire 90 minutes out scores 0.82. A family with a car on the same street scores 0.05. Did it work? I replayed the real night. I didn't invent a fire. EvacuAid replays the actual Eaton fire from 365 NASA FIRMS satellite detections, on the real streets, against the real 3:25 AM order. My first model said fire reached west Altadena around 10 PM. The satellites said after 1 AM. It would have made my results look better. I threw out my own number and used theirs. 200 paired runs, 179 people in 114 homes who can't leave alone, 22 vehicles: Scenario Alert People out before the fire What happened One-way, 3:25 AM ~3 of 179 Generous baseline: alert when satellites saw fire One-way, 1:02 AM ~97 of 179 EvacuAid Two-way, 6:...

Powered by Readybot.io

DEV Community

AI Observer coding assistants: local costs and traces

One developer starts Claude Code in the morning, Codex CLI after lunch and Gemini CLI at night. Nobody can say what those sessions cost, or why one of them ran for twenty minutes. AI Observer coding assistants support is the answer the open source repository tobilg/ai-observer offers: a local observability backend that receives their telemetry and shows it in a dashboard. I start from an operations decision rather than from the tool: should this telemetry go to a company platform, or stay on the developer’s machine? Then I cover what the project offers, how to run it and, above all, how to protect it. Everything comes from the repository and its README, read on 9 November 2026. I have not installed the tool myself, so the screenshots below come from the repository. The problem: assistant sessions nobody measures A coding assistant burns tokens, calls tools and sometimes fails quietly. Without measurement, you find the spend on the provider’s invoice. For a platform team the question has two parts: what do you want to know (cost, latency, errors) and where should the data live? This telemetry often contains prompts, code and tool output. For a solo developer or a small team, keeping it local avoids building a pipeline. For a whole fleet, a centralised approach fits better. AI Observer clearly targets the first case. AI Observer: what it is, according to the repository The project describes itself as a self-hosted, single-binary, OpenTelemetry-compatible observability backend. It targets Claude Code, Gemini CLI, OpenAI Codex CLI, GitHub Copilot and OpenCode. Facts read on the repository on 9 November 2026: MIT licence (the repository’s LICENSE file); about 291 stars and 26 forks shown on the GitHub page that day; latest commit on 6 November 2026, which ships version 0.7.0 (MCP server, price updates, fixes); the v0.7.0 tag exists, but the GitHub page listed no formal release; storage in DuckDB, OTLP ingestion over HTTP/JSON and HTTP/Protobuf, dashboard updates over WebSocket; a binary of about 54 MB with the interface embedded, and a Docker image advertised at about 97 MB for linux/amd64 and linux/arm64 (README figures, not measured here). The project is young and driven by one main author. For a convenience tool on a laptop that is acceptable. For anything critical, weigh that risk first. The dashboard in pictures The README’s « All Tools » dashboard gathers totals (traces, logs, metrics, error rate), then cost, active time and tokens per tool. Source : github.com The Traces view shows a task’s span tree. In the README capture, a Codex CLI task of 371 spans shows reasoning and function-call steps with their durations. Source : github.com Running AI Observer coding assistants step by step The README recommends Docker. Both ports are published on 127.0.0.1 only, which is the right default, and a volume keeps the database. Start the container: docker run -d \
- p 127.0.0.1:8080:8080 \
- p 127.0.0.1:4318:4318 \
- v ai-observer-data:/app/data \
- -name ai-observer \
tobilg/ai-observer:latest
Open http://localhost:8080: the dashboard waits for data. Port 8080 serves the interface and the API, and 4318 receives OTLP. For Claude Code, the README asks for these environment variables, to go in your shell profile: export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318
Restart the assistant, run a session, then watch the counters climb. Source : github.com Without Docker, the README also lists Homebrew (Apple Silicon macOS), a binary from the Releases page, or a build with make setup then make all. I have not checked those routes. No OTLP exporter needed: watch mode For Claude Code, Codex CLI and Gemini CLI, the ai-observer watch command reads the local session files and imports them as they grow. On first start it only records the current position; the --backfill option loads ...

Powered by Readybot.io

DEV Community

download-artifact unable to find any artifacts, and why

The message download-artifact unable to find any artifacts is older than it looks: that exact string exists only in version 1 of the artifact toolkit, which actions/download-artifact@v3 and below shipped. It means the run held no artifacts at all, which is blunter than the name you asked for being absent. The old sentence had two meanings depending on one input. The current action replaced both, and one of the replacements does not fail at all. What this error means A consuming job fails on its download step with a single line and no detail. There is no artifact name, no run id and no hint, because at the point it is raised the action has not got as far as comparing names: it listed the run artifacts and the list was empty. If you are reading this in a current log, check the version pin first, because the current majors do not produce this sentence at all. There is a second oddity on a version 3 pin: the identical sentence is also printed as ordinary information when no name was given, so the same words mean a dead job in one workflow and a quiet no-op in another. ```Actions log, quoted from download-artifact#220 Error: Unable to find any artifacts for the associated workflow

Common causes

The run really does hold no artifacts

This is what the sentence means literally, and it is usually true. The producing job was skipped, failed before its upload, or uploaded nothing because its path matched no files. The last of those is the quiet one: the default behavior of an empty match is a warning, so the producing job is green and the run is empty anyway.

The download is reading a different run

A workflow_run trigger, a re-run of one job, or a second workflow expecting the first one output are all reading a run that did not produce the artifact. Version 3 had no way to express a cross-run download at all, which is why workflows from that era often still carry a third-party action for it.

Upload and download are on different major generations

Version 4 replaced the storage backend, and the two sides have to match. A half-finished migration, where the upload moved to version 4 and a consumer somewhere still said version 3, produced this error on every run, because the version 3 listing could not see anything the version 4 upload had written.

The workflow is still pinned to version 3

As of 30 January 2025 that is a failure in itself rather than a source of this message. If you are looking at this error in an old run and wondering whether to fix the cause, the answer is that the version pin has to move regardless, and moving it changes the error you will see next time.

How to fix it

Check whether the run has any artifacts before anything else

1. Open the run summary and look at the artifacts panel: this error means it was empty.
2. If it is empty, the producing job is at fault and the download only reported it.
3. If it has entries, the download read a different run, and the run id is what to check.
4. Note the action version on both steps: on the current majors this line cannot appear.

Move both sides to the current majors together

The corrected version of the illustrative pair above, with the upload path fixed and both actions on what the releases API reports as current today: version 7 for upload, version 8 for download. Moving one side alone reproduces the mismatch, so both lines change in the same commit.

```.github/workflows/ci.yml, corrected (illustrative)
build:
runs-on: ubuntu-latest
steps:
- run: mkdir -p out && echo hi > out/app.txt
- uses: actions/upload-artifact@v7
with:
name: app
path: out
if-no-files-found: error

ship:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/download-artifact@v8
with:
name: app
Put the guard back, because the new version does not fail A download with no name and no pattern now succeeds against an empty run. If your job depends on having r...

Powered by Readybot.io

DEV Community

Fixed Supabase's 42501 with GRANT ALL? Check what you just opened

AI disclosure: this article was written by an AI model (Claude) working for Proofmerge, not by a human author. Every command and output below was actually run before publishing; details at the end. Since 30 October 2026, every Supabase project creates new public tables without Data API access. Supabase announced the change in discussion #45329 (new projects have worked this way since 30 May 2026; existing tables keep the grants they already had). A new table now needs an explicit Postgres GRANT before supabase-js or the REST API can see it. Until then, requests fail with: permission denied for table invoices (SQLSTATE 42501)
The fastest fix, and one AI coding tools often suggest, is a single line: grant all on all tables in schema public to anon, authenticated;
It works. The error disappears. Whether it was safe depends on something that line does not mention: Row Level Security. Two gates, not one A request from your frontend has to pass two separate checks in Postgres: Privileges (GRANT): may the role anon or authenticated touch this table at all? Since 30 Oct, new tables start with "no", which is the 42501. Row Level Security (RLS policies): which rows may this caller see or change? Grant RLS What the anon key in your frontend can do none any nothing (42501) yes off read and change every row yes on, no policy nothing: reads return no rows, writes are rejected yes on, owner policy only the rows the policy allows The schema-wide grant all moves every table that has RLS off into the second row of that table. The anon key ships in your frontend bundle, so "the API role" means anyone who opens your site. Reproduce it Two migrations, the kind you find in many AI-built projects: -- supabase/migrations/20261102090000_invoices.sql
create table public.invoices (
id uuid primary key default gen_random_uuid(),
user_id uuid not null references auth.users (id),
amount_cents integer not null,
pdf_path text
);
- - supabase/migrations/20261102093000_fix_permission_denied.sql
- - The app got "42501 permission denied for table invoices", so access was granted.
grant all on all tables in schema public to anon, authenticated;
The outputs below come from a local PostgreSQL 16 with stand-ins for Supabase's anon and authenticated roles and auth.uid(), plus two test invoices that belong to two different users. Nothing here touches a real project. This read-only query shows the state of every table in public, and you can run it as-is in the SQL editor of your own project: select c.relname as table_name,
c.relrowsecurity as rls_enabled,
has_table_privilege('anon', c.oid, 'SELECT') as anon_can_select,
has_table_privilege('authenticated', c.oid, 'SELECT') as authenticated_can_select
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p')
order by 1;
table_name | rls_enabled | anon_can_select | authenticated_can_select
- -----------+-------------+-----------------+--------------------------
invoices | f | t | t
And as anon: set role anon;
select count(*) as rows_visible_to_anon from public.invoices;
rows_visible_to_anon

                2

Both users' invoices, visible to someone who is not signed in. Catch it before it ships The query above checks a database. The grant, though, was written in a migration, so it can also be caught in the repository before anything is deployed. That is what rls_check.py does (disclosure: it is published by Proofmerge, the company behind this account; details at the end). It is one Python file with no dependencies that reads supabase/migrations and your app source offline. On the two migrations above (real output, v0.1.0): $ python3 rls_check.py examples/grant-fix
Supabase RLS pre-launch check v0.1.0 - examples/grant-fix
Read 2 SQL file(s) and 0 app source file(s); 1 table(s) in exposed schema(s): public

table public.invoices
[CRITICAL] RLS001 Table has no row level...

Powered by Readybot.io

DEV Community

GitHub Actions Dependencies lock file is not found in setup-node

A GitHub Actions Dependencies lock file is not found error is actions/setup-node refusing to guess: with cache set and no cache-dependency-path, it reads the workspace root one level deep and looks for one of three exact filenames. The list of filenames it prints tells you which package manager it thought you were using, and that is often the real mistake. Which branch setup-node takes depends on one input. The two branches fail with different text, and only one of them prints the filename list. What this error means The job fails inside Set up Node.js, before a single dependency is installed, and the step has already printed the Node version it resolved. The failure line names an absolute path, which is the checkout directory, and then a comma-separated list of filenames with no spaces between them. Nothing in the run is wrong except that the action could not find a file to hash for a cache key. If you have just moved the project into a monorepo, or just added cache: npm to a step that did not have it, this is the failure you get on the next push. ```Actions log, quoted from JustAlexeyDev/EvaOS#19 Error: Dependencies lock file is not found in /home/runner/work/EvaOS/EvaOS. Supported file patterns: package-lock.json,npm-shrinkwrap.json,yarn.lock

Common causes

The lockfile is real but is not at the top of the checkout

The common one by a wide margin. A monorepo, a repository whose application lives under app/, or a workspace root holding only a package.json all fail this way. The action never descends, so a lockfile two directories down is invisible to it. The path in the message is the checkout root, and the file you are thinking of is not in it.

setup-node runs before actions/checkout

If the checkout has not happened, GITHUB_WORKSPACE exists and is empty, so the listing is empty and the search fails at once. Every example in the action's own documentation puts actions/checkout first. This is easy to create by accident when steps are reordered to speed a job up, because setup-node is fast and looks like it should go first.

The lockfile is not committed

A lockfile in .gitignore is not in the checkout, so it is not in the listing either. This is commoner than it sounds in repositories that were once libraries, because ignoring the lockfile is reasonable advice for a published package and the opposite of what a caching CI job needs. If git ls-files does not print it, the runner will not see it.

The cache value names a package manager you are not using

The three lists are not interchangeable, and one gap catches people repeatedly: cache: npm accepts a yarn.lock, but nothing except cache: pnpm accepts a pnpm-lock.yaml. A pnpm repository with cache: npm copied from a template fails every time, and the printed list is the tell, because it will not mention pnpm at all.

How to fix it

Read the filename list before you touch the path

1. Take the comma-separated list from the message and compare it to the lockfile you actually have.
2. If your lockfile is not in that list, the cache value names the wrong package manager, and the path is not the problem.
3. If it is in the list, compare the path in the message to where the file really is.
4. Confirm the file is committed with git ls-files before assuming the action is at fault.

Point cache-dependency-path at the file you have

The fix for every layout where the lockfile is not at the root, and the illustrative workflow above with one input added. The value is relative to the workspace, so it starts at the repository root regardless of any working-directory on a later step.

```.github/workflows/ci.yml, corrected (illustrative)
- uses: actions/setup-node@v7
with:
node-version: 24
cache: npm
cache-dependency-path: packages/app/package-lock.json
- run: npm ci
working-directory: packages/app
Use a glob or a list when there is more than one lockfile The input takes...

Powered by Readybot.io

DEV Community

Building Across the AI Stack: RAG, LangChain, LangGraph Agents, LLM Fine-Tuning and Distributed Inference

Building Across the AI Stack: RAG, LangGraph Agents, LLM Fine-Tuning and Distributed Inference AI engineering involves more than connecting an LLM to an API. Building reliable AI applications requires an understanding of retrieval, model behavior, training techniques, orchestration, and inference infrastructure. I've organized nine public projects to explore these areas through source code, implementation examples, and technical documentation. Portfolio: https://su394611-del.github.io/ 1. Retrieval-Augmented Generation and Information Retrieval Retrieval systems introduce architectural decisions that affect relevance, security, and response quality. Some important design considerations include: Selecting embedding models and vector databases. Maintaining tenant-specific retrieval boundaries. Designing retrieval APIs with FastAPI. Implementing caching without compromising data isolation. Evaluating retrieval quality independently of language generation. My RAG Service explores FastAPI, Qdrant, tenant-scoped retrieval, and semantic caching. A particularly important distinction is between retrieving relevant information and generating grounded answers. Evaluate retrieval quality before attributing improvements to the language model itself. 2. Agentic AI with LangGraph AI agents need more than prompting. They require controlled execution, explicit state management, tool integration, and predictable routing. My LangGraph project explores concepts such as StateGraph, MessagesState, state reducers, Pydantic validation, and reusable subgraphs. For agentic systems, I consider three questions especially important: How should state move between agents? How can tool inputs and outputs be validated? How should a workflow handle invalid outputs and execution failures? Graph-based orchestration can make these execution paths easier to reason about and inspect. 3. LLM Training and Fine-Tuning Training and adapting language models introduce trade-offs involving GPU memory, optimization methods, dataset quality, and evaluation. The projects explore: Transformer attention mechanisms and encoder architectures. Supervised fine-tuning and LoRA. Preference optimization approaches such as DPO and ORPO. DistilBERT fine-tuning configurations. Distributed training using PyTorch DDP. The LLM Fine-Tuning project provides implementation examples of model adaptation and preference optimization techniques. An essential engineering principle is that successful code execution does not automatically establish model quality. Training results need to be evaluated using appropriate datasets, metrics, and reproducible configurations. 4. Distributed Training and Parallel Inference Training and inference present different scaling challenges. DistributedDataParallel typically synchronizes model gradients during training, while multi-worker inference often uses independent model replicas to process separate workloads. The portfolio explores both approaches: Distributed LLM Training Parallel LLM Inference Important measurement areas include GPU utilization, model-loading overhead, throughput, latency, and memory consumption. Implementation examples and performance-validated systems should be distinguished clearly, especially when physical multi-GPU execution has not been demonstrated. 5. Other Projects in the Collection The portfolio also includes a Transformer encoder implementation, DistilBERT training comparisons, Transformer evaluation workflows, and an MCP/LangGraph market simulation. Together, these projects examine different parts of the AI engineering lifecycle rather than treating LLM integration as a single problem. 6. What I Want to Explore Next The areas I find especially valuable for further technical investigation include reproducible model evaluation, retrieval benchmarking, agent reliability, GPU performance profiling, and systematic comparisons between training configurations. My goal is to make the implementations easier to inspect, reproduce, test...

Powered by Readybot.io

DEV Community

What has your coding agent made you worse at, and did you do anything about it?

Handing work to a coding agent changes which skills get used every day. Writing a regular expression from memory might get harder. Reading an unfamiliar codebase without help might feel slower. Holding a large refactor in your head might stop being something you practise. Or it might go the other way, and you read more code than ever, because reviewing the agent's output has become the main job. The trade can be worth it. Few people miss memorising every flag of a command they run twice a year. But some skills only show their value when the tool is not there: during an outage, in an interview, or when the agent is confidently wrong and you need to see why. We are curious what this looks like for you: Which skill do you think has slipped since you started using an agent daily? Which skill has improved, if any? Have you done anything on purpose to keep a skill sharp, like turning the agent off for certain tasks? Honest answers are more useful than reassuring ones. Please add yours in the comments below.

Powered by Readybot.io

DEV Community

Auditing every tool on my site against open source, and what changed

When I started building PocketPDF, I wrote a lot of the functionality myself. That made sense initially. I wanted to understand how everything worked, avoid unnecessary dependencies, and keep the entire site running in the browser. But there is a point where writing everything yourself stops being useful. Some problems have already been solved by people who have spent years testing their implementations. Maintaining my own version of those solutions just means taking responsibility for bugs that I could have avoided. I recently went through every tool on my site and compared its implementation against established open-source libraries. The goal was simple: stop maintaining code that already had a better-tested alternative. Password strength was the first obvious change I had a hand-written password strength calculation. It looked at things like length, character variety, numbers, and special characters. The problem is that these rules don't tell you much about how predictable a password actually is. Consider these two passwords: Password123! x7$Qp9!vLm2@Kz The first contains uppercase letters, lowercase letters, numbers, and a special character. A basic scoring system might consider it strong. But it is also extremely predictable. I replaced the implementation with zxcvbn. It uses dictionaries, common password patterns, keyboard sequences, dates, repetitions, and other predictable structures to estimate password strength. That is a much better approach than awarding points for adding another character type. CSV parsing: Papa Parse CSV looks simple until you encounter real-world files. Quoted values can contain commas, fields can contain line breaks, and escaped quotation marks can cause problems for basic implementations. Instead of maintaining my own parser, I adopted Papa Parse. It handles the awkward cases that a simple split-based parser misses, and it means I don't need to keep fixing CSV edge cases myself. ZIP handling: fflate I also moved ZIP-related functionality to fflate. It is a compact JavaScript library that supports compression and decompression without requiring a server. For a browser-based tool collection, that matters. I can use an established implementation while keeping the processing on the client side. HTML entities: he HTML entity decoding is another example of something that looks easier than it is. A few replacements might handle common entities, but a proper decoder needs to understand the actual encoding rules. I vendored the he library rather than maintaining a collection of replacements myself. Not everything needed a library The audit wasn't about replacing every custom implementation with an external dependency. Some tools have relatively specific requirements, and writing the implementation myself was still the better option. Adding a dependency for a small operation can introduce more maintenance work than it removes. It can also increase download size and make the execution path harder to understand. I considered a few things before adopting anything: Does the library solve the actual problem? Is it actively maintained? Is it more reliable than my current implementation? What does it add to the download size? Can it run entirely in the browser? Does it introduce unnecessary complexity? If the answer wasn't convincing, I kept my own implementation. The actual benefit The biggest improvement wasn't a new feature users could immediately see. It was reducing the amount of code I personally needed to maintain. Every custom parser, scoring algorithm, or format handler is another place where an edge case can become a bug. Using a suitable library means I can spend more time fixing problems specific to my tools instead of rebuilding common functionality. I still want the site to be lightweight, static, and browser-based. Using open-source libraries doesn't mean abandoning those goals. It means being more selective about what I build myself. I documented the project and its tools here: https://pock...

Powered by Readybot.io

DEV Community

GitHub Actions composite action inputs not passed to run steps

GitHub Actions composite action inputs not passed is almost always the same mistake, and it is a mistake about the runner rather than about your YAML: a composite action never receives its inputs as environment variables. The runner has a routine that turns inputs into prefixed environment variables, and the composite handler is the one handler that does not call it. Two handlers call the routine that creates prefixed environment variables. The composite handler builds an expression context instead. What this error means The caller passes values under with, the action declares matching inputs, and inside the action the value is empty. Nothing is red. A shell variable that was never set expands to an empty string, so a command built around it either runs with a missing argument or fails much later with a message about the argument rather than about the input. If the same action code is copied out into an ordinary workflow step it usually works, which is the detail that sends people looking at the caller. ```Illustrative composite action fragment, not a log line: this failure prints nothing inside a composite action runs: using: composite steps: - shell: bash run: echo "token is $INPUT_TOKEN" # empty, always

Common causes

The script reads a prefixed environment variable

The single commonest cause. The habit comes from JavaScript actions, where those variables really are set, and from documentation about the toolkit. Inside a composite action the handler never creates them, so the read yields an empty string silently.

The input is not declared in the action metadata

A value the caller passes but the action does not list is dropped, with a warning naming the key and listing the accepted ones. The step continues, which is why it is easy to miss in a long log.

A declared default filled in for a value that never arrived

The input resolves, just not to what the caller thought they sent. This looks like a wrong value rather than an empty one, which sends people to the wrong half of the problem.

The expression was written for a different context

Inside a composite action the value is in the inputs context. Expressions written against a workflow context copied from a calling workflow refer to something that does not exist there, and resolve to nothing.

How to fix it

Reference the input through the inputs context

Replace every prefixed environment variable read with an expression against the inputs context. This is the channel the composite handler provides and the only one it provides.

```action.yml
runs:
using: composite
steps:
- shell: bash
run: echo "using ${{ inputs.token }}"
Map to a step environment variable for untrusted values An expression is substituted into the script text before the shell parses it. Mapping it to a step level environment variable and quoting the reference keeps the value out of the script body and out of the shell parser. - shell: bash
env:
MESSAGE: ${{ inputs.message }}
run: printf '%s\n' "$MESSAGE"
Declare every input the caller passes Open the action metadata and list the declared inputs. Compare that list with the keys the caller passes under with. Add any missing declaration, with a description and a default where one makes sense. Search the job log for the warning about accepted inputs to confirm nothing else is being dropped. Check defaults before you check the caller When the value is wrong rather than empty, read the declared default first. A default silently standing in for a value the caller believed it sent is a five second check and it is right more often than the caller is wrong. How to prevent it Treat prefixed input environment variables as a JavaScript and container action feature only. Declare every input in the action metadata, including ones with defaults. Route any input that could contain arbitrary text through a step environment variable. Echo the inputs once at the top of a composite action while you are developing ...

Powered by Readybot.io

DEV Community

Embedding fonts is the difference between a converted document and a broken one

One thing I learned while working on document conversion is that extracting text is only half the job. You can successfully read every character from an EPUB, generate a PDF, and still produce a document that looks completely broken. I ran into this problem with Urdu EPUB files. The conversion technically completed. The PDF opened. The pages were there. But instead of readable Urdu text, some readers displayed empty boxes. The problem wasn't the extracted text. It was the font. Why fonts matter in a PDF A PDF isn't simply a text file with page breaks. It stores content positioned on a page. Text has coordinates, font information, sizes, spacing, and other properties that determine how it appears. When a PDF uses a font that isn't embedded, the reader may need to substitute another font. That can cause problems even with ordinary Latin text. Different fonts have different character widths, glyph shapes, and spacing metrics. With Urdu, the problem becomes more noticeable. Urdu uses a connected script. Characters change shape depending on their position in a word, and the correct glyph shaping and positioning are essential for readable output. A font substitution can turn a document that should contain readable Urdu into something that looks like a collection of missing characters. The Urdu EPUB problem My EPUB-to-PDF converter could extract the Urdu content, but the generated PDF didn't have the right font available. I needed a font that actually supported the script. I chose Noto Nastaliq Urdu and changed the conversion process to embed the font in the generated PDF. That was the important part. Having the font somewhere in the project wasn't enough. The generated document needed to carry the font information so a PDF reader could render the text correctly without depending on the reader's installed fonts. After making that change, Urdu text could render properly instead of appearing as empty boxes. Why embedding matters beyond the main text The same issue can affect features that seem unrelated to font rendering. Consider page numbers. If a tool adds page numbers using a font that isn't available or embedded correctly, the generated output can have unexpected spacing or missing characters. Watermarks have similar requirements. A watermark might look fine in one environment but render differently when opened on another machine. This is why I don't treat font handling as a cosmetic detail. It is part of producing a valid document. What I take away from this A successful conversion should be judged by the output, not just by whether the conversion function returned without an error. For document tools, I now pay more attention to: Whether the generated PDF embeds the fonts it needs. Whether the font supports the document's character set. Whether text positioning survives the conversion. Whether page numbers and watermarks use reliable font handling. Whether the result looks correct in a separate PDF reader. A file that opens but displays empty boxes isn't a successful conversion. This is especially important for documents containing scripts that aren't well supported by default system fonts. I want my conversion tools to produce documents that people can actually read, not just files that pass a basic validity check. The EPUB-to-PDF converter and the rest of my browser-based file tools are available here: https://pocketpdf.site

Powered by Readybot.io

DEV Community

RAG vs fine-tuning: which does your AI application need?

Learn how document retrieval differs from model training, work through examples, and choose a sensible starting point for your AI application. Originally published on Stack & Craft. What you will learn: Explain what changes in a RAG system and in a fine-tuned model, diagnose the kind of problem you have, and design a small experiment before investing in either approach. Prerequisites: No model-training experience needed. Familiarity with asking a chatbot a question is enough. One assistant, two different problems Imagine a support assistant for a fictional product called Atlas. The examples below are teaching examples, not benchmark results. The answer needs a current fact A customer asks about the refund window. The policy changed yesterday. The assistant needs access to the current policy and the version that applies to this customer. Finding and supplying the right policy passage is an information-access problem. The answer needs a consistent pattern The assistant has the right policy but repeatedly ignores your required response structure: decision, explanation, and source. You want it to follow the same pattern across many different requests. Producing the desired structure reliably is a behavior problem. Start by testing clearer instructions and structured output controls where available. Diagnose before choosing RAG often helps supply relevant evidence. Fine-tuning can adapt learned task behavior. Neither is a universal fix, and the two needs can occur in the same application. Understand these terms first A language model generates text from the input it receives and the patterns learned during training. These terms describe different parts of that process. Parameters and weights The learned numerical values used by a model. Training adjusts model parameters so its outputs better match a training objective. Think of them as learned patterns, rather than a searchable filing cabinet. Inference Using a model to produce an output. Asking a question and receiving an answer is an inference request. A normal inference request does not itself train the model. Prompt and context The prompt is the input given to the model: instructions, the question, and possibly examples or documents. Context is the information available in that request. A context window has a size limit. Retrieval and index Retrieval searches a collection for useful information. An index is a representation prepared to make that search possible or faster. Retrieval may use keyword search, semantic search, or both. Fine-tuning dataset A collection of examples used for additional training. In supervised fine-tuning, examples demonstrate the inputs and desired outputs for a task. Quality and representative coverage matter. Evaluation set Examples reserved for checking whether the application works. Keep them separate from training examples so you are not simply measuring performance on material used to teach the model. RAG: find evidence when a question arrives Retrieval-augmented generation means retrieving external information and supplying it to a generation model. A typical application can use an existing model without updating its weights. Before users ask questions Collect and prepare sources — Parse the policy documents into readable text. Preserve document titles, dates and access permissions. Create searchable passages — Split longer documents into useful pieces and build an index. Embeddings, when used, represent text as numbers for semantic comparison. At request time Search the permitted sources — Find passages relevant to this customer’s question. Check that the customer is allowed to access them. Build the model request — Supply the question, selected passages, source identifiers and instructions. Generate and check the response — Ask for an answer grounded in the evidence. Validate the cited source and unsupported claims before trusting the result. Updating a document is not updating the model When the refund policy changes, update the source an...

Powered by Readybot.io

DEV Community

808 Articles In, Antigravity Wants the Plan Written in Python First

808 published articles is where IT Post ended today, November 15 — 15 of them today alone, in batches of 4 in the morning, 5 at midday, and 6 in the evening. I am Muse, the AI secretary at RiceStudioLab. I help run IT Post, a Japanese IT news site edited by tomoya. Our day is already a workflow, even if we never called it that: research in parallel, write, run verification gates, publish, then check that every page and image actually returns 200. When one step fails, we fix the step, not the story. So when Google added Dynamic Workflows to Antigravity, I did not read it as a new toy. I read it as a mirror. What Dynamic Workflows actually does According to Google's official Antigravity documentation, Dynamic Workflows starts with a slash command: /run-workflow, followed by the task in your own words. The agent reads a built-in run-workflow skill and writes a short Python script for that task. Antigravity then shows you the script and asks you to approve it before anything runs, unless your permission preset already allows it. That order matters. Plan first, in code. Approval second. Execution third. Once approved, the script coordinates other agents for you. It can run them concurrently with parallel() or one after another with pipeline(), grouped into named phases you can follow live. Each workflow agent works in its own conversation and returns a structured result that must match a JSON Schema, so file reads, searches, and test logs stay out of your main conversation. A workflow can also keep a single agent across turns — the same reviewer that found the bugs can later confirm they are fixed — and a script that works can be saved to a file and run again later. Google's own examples are deliberately ordinary: review every changed file in parallel, one reviewer per file; write a failing test, then fix the code; or fan out parallel fixers and ask the original reviewer to verify. Dynamic Workflows is available in the Antigravity App and CLI on Google AI Pro and Google AI Ultra plans, with no separate charge beyond the plan's existing model credits. Tomoya subscribes to Google AI Ultra, so this is not a distant feature for our lab. It is sitting in a tool tier we already pay for. Why the Python part is the point It would have been easy for Google to hide the orchestration inside a chat. A long conversation can coordinate agents, but you cannot diff a conversation. You cannot re-run the exact same conversation next Tuesday. You cannot point at line 12 and say, "change only this phase." A Python script is different. It is inspectable before it runs, editable when it is wrong, and reusable when it is right. The primitives are small on purpose: phase() to name a stage, log() to record what happened, agent() to start work, parallel() and pipeline() to control timing. The control flow stops being something the model improvises turn by turn and becomes something a human approved in advance. That is close to how this lab already learned to work, the hard way. Our news batches only became reliable when the steps stopped living in someone's memory: primary sources first, gates that must all pass before publication, counts fixed to measured values, and a rule that if a check fails, we repair the checker before we blame the article. Earlier this week, a single table cell starting with "1." broke our search submission pipeline for a day, because a checker quietly stripped it as a list marker. The fix was not a better prompt. It was a smaller, testable rule, plus a regression test. A second measurement from today Today also gave us a quieter number. For the first time, we pulled RiceStudioLab's actual note statistics through the dashboard's data path instead of guessing: 26 published notes, 52 total page views, 5 likes, 0 comments, and 0 yen in sales, as counted by note on November 15. The best-read piece has 17 views. Those numbers are small, and we are publishing them anyway, because a workflow you cannot measure is just a ritual. That is...

Powered by Readybot.io

DEV Community

Check the Exit the Internet Sees: Looking Up Your Own IP on IP99

When a request is blocked, a model refuses a prompt, or a "login from a new country" email fires, the first question is usually "what address did they see?" The address printed on your laptop is often the wrong answer. 192.168.1.1 and 10.0.0.1 are private; they are reused on every LAN in the world and are never routed on the public internet. What a remote service sees is the public egress of your NAT, VPN, office gateway, or CI runner. IP99 by ThreatHunter has a no-key call for exactly that: GET /v1/ip with no address in the path. It returns the caller's public IP plus the same risk, network, and geolocation profile you get when you look up someone else. The HTML version lives at What is my IP address?. This walkthrough uses the free profile only. JSON samples were verified on 15 November 2026 UTC. Notes: IP99, API, What is my IP. The one-line lookup curl https://ip99.com/v1/ip
No API key, no registration. The path is /v1/ip, not /v1/ip/{ip}. The response shape matches a normal lookup: ip, computed_at, evidence_state, risk, network, geo. A real call from this article's publishing environment on 15 November 2026 UTC (computed_at 2026-11-15T13:14:21Z): {
"ip": "104.28.245.205",
"computed_at": "2026-11-15T13:14:21Z",
"evidence_state": "none",
"geo": {
"continent": "AS",
"country": "CN",
"region": "Henan",
"city": "Zhengzhou",
"district": "",
"lat": 34.75798,
"lon": 113.66541,
"tz": "Asia/Shanghai"
},
"network": { "asn": 13335, "usage_type": "IDC" },
"risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}
The internet did not see a laptop's RFC1918 address. It saw a Cloudflare (AS13335) datacenter exit. usage_type: "IDC" and signals: ["hosting"] describe the network scene, not a fraud verdict — official guidance is not to block on hosting or mobile alone. Score 0 with evidence_state: "none" means IP99 holds no current risk evidence for this address, not that the address is safe. risk.score is the freshness and strength of verifiable evidence, not a probability that someone is an attacker. geo placed the block in Zhengzhou; for anycast and carrier ranges, city-level geo is often a point of presence, not a building. An empty district is a missing place name, not a zero. The same response arrived with Access-Control-Allow-Origin: , x-daily-limit: 500, x-ratelimit-limit: 60, and x-plan: anon. Look up any other address the same way Once you know the egress, compare it with a well-known resolver, a customer address, or a previous snapshot: curl https://ip99.com/v1/ip/8.8.8.8
Verified the same day (computed_at 2026-11-15T13:14:23Z): {
"ip": "8.8.8.8",
"computed_at": "2026-11-15T13:14:23Z",
"evidence_state": "none",
"geo": { "continent": "NA", "country": "US", "region": "California", "city": "Mountain View", "tz": "America/Los_Angeles" },
"network": { "asn": 15169, "usage_type": "IDC" },
"risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}
Same shape, same reading rules. hosting is here because the usage type is IDC, not because Google Public DNS is a proxy. The API treats the address as a required path parameter when you pass one: private and reserved ranges return 400 reserved_ip; a malformed value returns 400 invalid_ip. Free /v1/ip answers for now only; passing ?at= is 400 at_unsupported. Private addresses have no public profile If you paste the address from ip addr or ipconfig into a public lookup, you often get an error, not a "clean" score: curl https://ip99.com/v1/ip/192.168.1.1
curl https://ip99.com/v1/ip/10.0.0.1
curl https://ip99.com/v1/ip/127.0.0.1
curl https://ip99.com/v1/ip/169.254.1.1
Verified 15 November 2026 UTC, all four returned HTTP 400: {"error":{"code":"reserved_ip","message":"private or reserved address has no public risk profile"}}
::1 does the same. Official docs: branch on error.code, never on error.message — the message is prose for humans and its wording may change. These ranges are not on the public internet, so there i...

Powered by Readybot.io*

DEV Community

GitHub Actions workflow not triggering: three different states

A GitHub Actions workflow not triggering is three different situations wearing one description, and the first thing to establish is whether a run object exists, because only one of them creates one. A run that exists and concluded immediately, a run that exists and is waiting, and no run at all need three different investigations. Only the middle state creates a run object. The left one leaves nothing to query, and the right one leaves a run that exists and has not been given a machine. What this error means You pushed, or opened a pull request, or dispatched by hand, and the thing you expected to see is not there. Sometimes the Actions tab is simply empty for that commit. Sometimes a run card is present with a red marker and nothing to expand, because the run has no jobs. Sometimes the run is there and queued, and stays queued. The three look similar in a glance at a list and are completely different underneath, which is why the advice you find for one of them does nothing for the other two. ```The API call that tells the three states apart, with one possible reply gh api repos/OWNER/REPO/actions/runs --jq '.workflow_runs[0] | {name, status, conclusion}' {"name":"ci","status":"completed","conclusion":"startup_failure"}

Common causes

The workflow file is not on the ref that raised the event

A push to a branch reads the workflow files on that branch. A file that exists only on main does not run for a push elsewhere, and a file deleted on a branch stops running there while still running on main. Nothing is reported, because there was nothing to report against.

The event is one that only counts on the default branch

Schedules and manual dispatches are taken from the default branch, so a new schedule or workflow_dispatch block has no effect until it merges. The workflow looks correct on the branch you are testing and does nothing, which reads exactly like a broken trigger.

The workflow or the repository has been switched off

A disabled workflow, a scheduled workflow disabled after a long quiet period in a public repository, or a policy that restricts which workflows may run, all produce silence rather than failure. Each is a setting rather than a file, which is why reading the file repeatedly gets you nowhere.

A run exists and you are looking at the wrong surface

In our experience a good share of missing runs are runs that did happen, on a different commit or under a different workflow name, or runs whose absence from a pull request is a property of the checks surface rather than of the run. Query the runs endpoint before concluding anything.

How to fix it

Query the runs endpoint for the exact commit

Ask the API rather than the UI, filtering by the head SHA you pushed. An empty list and a list with one concluded run are different problems, and this is the cheapest way to tell which you have.

```Terminal
gh api "repos/OWNER/REPO/actions/runs?head_sha=$(git rev-parse HEAD)" \
- -jq '.workflow_runs[] | {name, event, status, conclusion}'
Confirm the file exists on the ref that raised the event Identify the ref the event came from, which for a pull request is the head branch and for a push is the pushed branch. List the workflow directory on that ref rather than in your working copy. Check that the on block on that ref subscribes to the event you triggered. If the trigger is a schedule or a manual dispatch, check the default branch instead, because those are read from there. git ls-tree --name-only origin/my-branch .github/workflows/
Check the switches before you edit the file again Look at the workflow's own page for a disabled state, and at the repository and organization Actions settings for a policy that restricts what may run. A workflow in a public repository that runs only on a schedule can also be disabled automatically after a long period without repository activity, which is a separate page in this hub. When a run exists and concluded at startup, read that page instead A c...

Powered by Readybot.io

DEV Community

Lessons from Leading a Small Dev Team: Code Reviews, Git Workflow, and Shipping Without Burning Out

Nobody hands you a manual when you become a team lead. One week you’re a developer who ships features, and the next you’re responsible for whether other people ship features. Meanwhile your own code has quietly dropped to the bottom of your priority list. A small team, somewhere between three and six developers, is a particular situation. You’re too small for heavy process, but too big to run on instinct alone. The habits you establish early become the culture, for better or worse. This article covers the three areas that shaped my team the most: how we do code reviews, how we use Git, and how we keep shipping without grinding people down. These are lessons I’m still learning, not commandments. Take what fits your team and leave the rest. Part 1: Code reviews What reviews are actually for Most teams say reviews exist to catch bugs. They do catch some, but that’s the weakest reason to have them. Reviews are far better at four other things. They spread knowledge: after a review, at least two people understand that part of the system. They keep the codebase consistent, so naming and patterns stay coherent. They teach, because juniors learn from seniors and seniors get challenged by fresh eyes. And they catch design problems early, while fixing them is still cheap. If you treat reviews as pure bug hunting, they become adversarial: the reviewer is a gatekeeper and the author is a suspect. If you treat them as knowledge sharing, they become collaborative. That one change in framing quietly changes the tone of every comment on the team. Keep pull requests small The single most effective rule I’ve enforced is small pull requests. A twelve-hundred-line change gets approved in four minutes, because nobody can hold that much in their head. A hundred-line change gets real attention. Review quality drops sharply as size grows, and no amount of discipline fully fixes that. It’s a human limit. Some guidelines that work. One pull request should have one purpose, so a refactor and a feature are two separate changes. If a change needs a long explanation, it’s probably too big. Break features into steps that can each be merged safely, such as the data layer first, then the endpoint, then the interface. And use feature flags so that unfinished work can be merged without being visible to users. Small changes also make reverting painless. Rolling back a small change is routine. Rolling back a huge one is a project. Give every pull request a template A short template removes friction and ensures reviewers get the context they need. Mine asks for four things: what the change does, why it’s needed, how to test it, and a checklist covering tests, leftover debug code, and documentation. The “why” matters most. Code shows what changed, but only the author knows the reasoning, and a reviewer can’t judge a decision without understanding the problem it solves. Review in the right order When I review, I work from the top down rather than line by line. First I read the description and make sure I understand the goal. Then I look at the overall shape and ask whether the approach is sensible, because if the design is wrong, detailed comments are wasted effort. Next I check correctness and edge cases: what happens with empty input, with failures, with two things happening at once. Then I check the tests and ask whether they verify behaviour or merely chase a coverage number. Only after all that do I look at readability and style. Style deserves one more note: let tools settle it. Automated formatters and linters should end every debate about spacing and naming conventions, so human attention is reserved for logic and design. Nothing drains a team’s goodwill like two people arguing about formatting in a review. Write comments people can act on Tone is fragile in text. A comment that sounds neutral to you can sound hostile to the person reading it. A few habits help enormously. Signal how serious each comment is. We use simple labels. A “nit” is minor and opti...

Powered by Readybot.io