DEV Community: Siddharth Pandey

Your retry logic is correct and does nothing

Siddharth Pandey — Mon, 24 Aug 2026 18:12:14 +0000

A comment on one of my posts sat open as an issue for two weeks before I understood how bad the thing it described actually was.

The post was about an AI assistant missing the SQS trigger on a Lambda. Mads Hansen replied with a sentence I have not been able to unthink since: the trigger shape is the first contract, delivery and retry semantics are the second. Getting event.Records[0].body right tells you how to read a message. It tells you nothing about what happens when one of ten messages in a batch throws.

I filed it as issue #87. The first item on that list is a bug no code reviewer can catch by reading the code, because the code is fine.

The handler that is correct and does nothing

Here is a batch consumer. It is the shape you get if you read the AWS docs and follow them.

export const processOrders = async (event: { Records: { messageId: string }[] }) => {
  const batchItemFailures: { itemIdentifier: string }[] = [];
  for (const record of event.Records) {
    try {
      await handleOrder(record);
    } catch {
      batchItemFailures.push({ itemIdentifier: record.messageId });
    }
  }
  return { batchItemFailures };
};

Nine records succeed, one throws, and the handler reports exactly the one that failed. That is the entire point of a partial batch response: the nine that worked are deleted from the queue, the one that failed comes back on its own.

Except this handler does not do that, because whether anyone listens to that return value is not decided in this file. It is decided by the event source mapping. If FunctionResponseTypes on the mapping does not contain ReportBatchItemFailures, Lambda discards the array. The whole batch is marked failed. All ten records are redelivered, including the nine that already ran to completion.

The failure mode is duplicate processing. Nine orders get handled twice, or twenty times, because one poison message keeps replaying its batch until the queue's retry limit. If your handler is not idempotent, that is double-charged customers, not a log line.

Why nobody catches this in review

Read that handler again with a critical eye. There is nothing wrong with it. It builds the array correctly, it uses messageId as the identifier, it catches per record rather than around the loop. A unit test that feeds it ten records and asserts one entry in batchItemFailures passes.

That is what makes this different from an ordinary bug. The code is not wrong. It is inert. The half of the contract that would make it work lives in a Terraform module in a different repository, or in a CDK stack a different team owns, or in a checkbox someone clicked in the console eighteen months ago. Nothing in your editor, your linter, or your test suite has any visibility into it.

And an AI assistant, asked to "add partial batch failure handling to this consumer," writes exactly the handler above and reports the job done. It is not hallucinating. It wrote the only half it can see.

Two ends of the same contract, two different findings

When I built the check into Infrawise, it became clear the mismatch has two directions and they are not equally bad.

The first is the mapping-side gap. MissingPartialBatchResponseAnalyzer looks for an sqs, kinesis, or dynamodb trigger with a batch size above 1 and no ReportBatchItemFailures. A batch of one has nothing to partially fail, so it is skipped. This one is graded medium: it is a missing capability, but the handler may genuinely not need it.

The second is the mismatch. BatchResponseMismatchAnalyzer fires when the code builds a batchItemFailures array and the mapping for that trigger has the setting off. That is graded high, and the description says why:

The code reads as correct and its unit tests pass; only the mapping tells the truth.

A missing setting is an absence. A mismatch is an active false belief — someone wrote the handler on purpose, believing per-record reporting was on. Every downstream decision they made about idempotency rests on that belief.

Detecting the code side is cheap. Both scanners just match the name: ts-morph looks for a property or shorthand property called batchItemFailures, and the Python scanner matches the same dict key. There is no control-flow tracing to a return statement, because building an array by that name has no other purpose in a Lambda handler.

The infrastructure side costs nothing either. FunctionResponseTypes rides on the ListEventSourceMappings response that trigger extraction already pages through, so the whole check is a field carried forward plus two analyzers.

The rule that keeps it honest

One detail mattered more than the analyzers themselves. Both checks fire only on an explicit false:

// Only an explicit false is evidence. undefined means the mapping was
// never read, and this finding would be an accusation without evidence.
if (trigger.reportsBatchItemFailures !== false) continue;

If a lambda:ListEventSourceMappings call was denied by IAM, or the page failed halfway, the field is undefined, not false. Treating that as "the setting is missing" would produce a high-severity finding about a mapping nothing was ever read from.

That failure would be worse than staying silent. A tool that occasionally accuses you of a bug you do not have gets muted, and then it is not there on the day it is right. So the extractor raises a partial-extraction error carrying whatever it did page through: the data survives, the source is recorded as partial, and the tools report it as unread rather than reporting a clean bill of health.

What actually changed in the loop

Two things, both small.

Before writing a batch consumer, analyze_function now returns the trigger with batchSize and reportsBatchItemFailures alongside the event shape, and get_lambda_overview carries the same fields for every function. So the assistant knows, before it writes a line, whether the partial-batch response it is about to build will be read or discarded. If it is going to be discarded, the honest answer is either "set FunctionResponseTypes first" or "make this handler idempotent," and now that answer is available at coding time.

And because the mismatch is graded high, infrawise check fails the build on it at the default --fail-on high. The mapping-side gap at medium does not — it is a suggestion, not a broken promise. A handler that reports failures nobody reads is a broken promise.

Key takeaways

A partial batch response has two ends. The handler returns batchItemFailures; the event source mapping must set FunctionResponseTypes: ["ReportBatchItemFailures"]. One without the other is not half a feature, it is zero.
Correct code can be inert. The bugs that survive review are the ones where the file is right and the thing it depends on lives somewhere your tooling never looks.
Grade the mismatch above the gap. A missing setting is an absence. A handler written to use a setting that is off is a false belief the rest of the design rests on.
Never infer a setting is off from a read that failed. undefined and false are different answers. A tool that conflates them will eventually be wrong loudly, and after that nobody reads it.
Until both ends are in place, the handler must be idempotent. That is not a workaround, it is the only thing standing between a poison message and processing the same order ten times.

Infrawise is open source and exposes this through MCP, so your assistant reads the mapping's real configuration instead of assuming. GitHub · npm

Your monorepo remembers infrastructure you deleted

Siddharth Pandey — Mon, 17 Aug 2026 13:18:05 +0000

A tool told someone to deploy a table from a stack they had deleted

Three bug reports arrived from one person running my analyzer against a CDK monorepo fronted by a single CloudFront distribution. The commit that fixed them describes the worst one in a line: stale cdk.out templates were being reported as live infrastructure.

That sounds mild. Here is what it actually produces. The shape is now a checked-in regression fixture, so I can show it with the fixture's names rather than anyone's real ones:

  1.  MED    IaC drift: DynamoDB table "LegacyInvoicesTable" defined in IaC but not deployed
       "LegacyInvoicesTable" is in cdk.out/LegacyBillingStack.template.json but not found
       in AWS. It may be undeployed or deleted manually.
       → Run `terraform apply` / deploy your stack, or remove the definition from IaC.

That table is not missing. LegacyBillingStack was deleted from the app. The table is correctly absent from AWS, and the tool is recommending its return.

Worse than the wrong answer is the wrong answer's provenance. "It is in your IaC, at this file path" is the kind of statement that ends an argument. An assistant reading that finding has no reason to doubt it, and every reason to write code against a table that does not exist or to helpfully re-add the stack.

How a deleted stack keeps its template

cdk synth writes one CloudFormation template per stack into cdk.out, plus a manifest.json describing the app. Delete a stack from the app, or rename it, and the next synth writes the new set of templates. The template from the deleted stack is still sitting there from the last synth that included it.

Two properties of a monorepo turn that leftover file into a real problem.

cdk.out is a build directory, and the .gitignore that cdk init generates lists it. Nothing in git status, nothing in a code review diff, nothing in CI will ever show you a stale file in there. It exists only on developer machines and build agents, which is exactly where analysis tools run.

And in a monorepo you cannot see it by looking. On a single-stack app, an extra .template.json next to your one real one is noticeable. With a dozen stacks in one repo, and stacks getting split, merged, and renamed as the repo grows, one extra file among thirteen is invisible. The repo with the most stack churn is the repo where leftovers are hardest to spot.

The file itself gives you no help either. An orphaned template is valid CloudFormation. Parse it and you get a table name, a key schema, a billing mode, an SQS queue, an output with an Export.Name, all structurally identical to the live ones. Nothing inside the file says the stack that produced it no longer exists.

Why everything downstream believes it

Follow the orphan forward and every consumer inherits the error.

The drift analyzer compares what is declared in IaC against what was extracted from AWS. Every resource in the dead stack lands on the declared side and nothing on the deployed side, so each one becomes a "defined but not deployed" finding. A deleted stack does not produce one wrong finding, it produces one per resource, all medium severity, all confidently sourced to a real file path on disk.

The graph gets the same resources as nodes, so a question like "which tables exist in this service" is answered with a table that was decommissioned two quarters ago.

Cross-stack exports are the sharpest edge. The orphan's Outputs section still carries Export.Name: demo-legacy-invoices-table-arn, which reads as an export you can Fn::ImportValue against. That import compiles, synths, and fails at deploy time, because the export was removed from CloudFormation along with the stack.

And notice what the naive fix breaks. If you simply drop the orphan's outputs along with its resources, a dead cross-stack export becomes silently missing rather than visibly wrong, and the next person to go looking for demo-legacy-invoices-table-arn gets nothing back with no explanation. Those two cases need opposite treatment.

The file the build rewrites every run

cdk.out/manifest.json is the one artifact that knows what the app looks like today. cdk synth rewrites it every run, and it lists exactly the stacks the app instantiates, as aws:cloudformation:stack artifacts each pointing at their templateFile. That is true whatever language the CDK app is written in, because the manifest is the assembly contract, not a TypeScript detail.

So a *.template.json that no manifest artifact points at is an orphan from a deleted or renamed stack. That gives three grades of confidence, and they get three different treatments:

Not in the manifest. Its resources are excluded entirely: they never reach the graph, so they never reach the drift analyzer, and nothing downstream can act on them. Its outputs are kept and marked stale: true with the reason, so a dead export stays visible instead of vanishing.

In the manifest, but the file's mtime lags the newest template by more than an hour. Flagged, resources kept. Synth rewrites every template each run, so a lagging timestamp is real evidence of something, but a weaker kind, and excluding resources on it would throw away live infrastructure over a clock skew.

No readable manifest. No cross-check is possible, so nothing is flagged and nothing is excluded. Absence of evidence is not evidence.

That last rule is not a nicety. A tool that flags resources on a guess trains you to skim past its findings, and then it does not matter what it detects.

The exclusion that did not hold

Excluding orphans in the CDK parser was not enough, and the bug that followed is the kind you only find by testing the whole pipeline instead of the unit.

There is a second parser for hand-written CloudFormation templates, and it walks the repo recursively. It walked straight into cdk.out and re-admitted the orphaned stacks under a cloudformation source, so the resources the CDK path had just excluded came back in through the side door. The exclusion looked correct in isolation and did nothing in practice.

cdk.out is now on the recursive scan's excluded-directories list, alongside node_modules, .git, and dist, with a comment saying why: that directory belongs to the CDK parser, which cross-checks it. The regression test asserts on both entry points, the CloudFormation extractor and the combined one, because only the combined one catches this class of bug.

The remaining tests are the negative controls: resources from an unlisted template stay out, its outputs stay in with the flag, a lagging mtime raises the flag while keeping the resources, and with no manifest present every template is treated as current.

What changed in the loop

The drift report stopped inventing work. get_stack_outputs returns stale and staleReason per output, and the tool description tells the assistant in as many words not to rely on a stale export without re-synthesizing, so the model does not have to infer what the flag means.

The demo carries the broken shape on purpose as a checked-in fixture: a manifest.json listing one stack, and an orphan template next to it whose table and queue must not appear anywhere while its export must appear flagged. Delete the manifest and both stacks are treated as current again, which is the third rule made visible.

If you run a CDK monorepo, the check you can do right now without any tooling: list cdk.out/*.template.json, list the templateFile values in cdk.out/manifest.json, and diff them. Anything in the first list and not the second is a stack your app no longer builds, still describing infrastructure to anything that reads that directory.

GitHub · npm

Key takeaways

Build output outlives source. A deleted or renamed CDK stack leaves its synthesized template in cdk.out, and because that directory is gitignored, no review or CI step will ever show it to you.
Ground "what exists" in the file the build rewrites every run. cdk.out/manifest.json lists the stacks the app instantiates today. The templates beside it only record what it once did.
Exclude dead resources, keep dead exports, flag them. They are opposite failures: a resource that no longer exists must not be acted on; an export that no longer exists must not disappear silently.
Absence of evidence is not evidence. With no manifest to check against, the honest output is nothing at all, not a guess in either direction.
Test the pipeline, not the unit. A correct exclusion in one parser was undone by a second parser recursing into the same directory. Only an end-to-end assertion caught it.

An empty result is not an all clear

Siddharth Pandey — Thu, 13 Aug 2026 17:04:57 +0000

An infrastructure audit runs across your account and comes back with two findings on S3. You fix both, close the ticket, and move on.

What the report did not tell you is that the role running it lacks s3:GetEncryptionConfiguration. Fourteen buckets returned AccessDenied on that call. The tool caught the rejection, wrote encrypted: false, and moved on to the next bucket. Some of those fourteen are encrypted. Some are not. The report cannot tell you which, because the value it printed was not read from AWS — it was the default that got assigned when the read failed.

This is the bug I spent a release fixing across Infrawise, and it is not really an S3 bug. It is a shape-of-data bug that almost every infrastructure scanner has somewhere: a boolean field with two states being asked to carry three.

`false` is a claim, and a failed call has no claim to make

The S3 extractor issues four calls per bucket — notifications, versioning, encryption, public access block — through Promise.allSettled, so one rejection never takes down the other three:

const [notifResult, versionResult, encryptResult, pabResult] =
  await Promise.allSettled([
    client.send(new GetBucketNotificationConfigurationCommand({ Bucket: name })),
    client.send(new GetBucketVersioningCommand({ Bucket: name })),
    client.send(new GetBucketEncryptionCommand({ Bucket: name })),
    client.send(new GetPublicAccessBlockCommand({ Bucket: name })),
  ]);

allSettled is the right primitive. The mistake was what happened next. Reading a rejected result as false collapses two completely different situations into one byte:

We read the bucket and versioning is off. An observation. Worth a finding.
The call was denied, throttled, or timed out. Not an observation. Worth an error message and nothing else.

Downstream, nothing can separate them again. The analyzer receives versioned: false and emits a medium-severity finding recommending you turn versioning on for a bucket whose versioning state was never read. The finding looks exactly like a real one. It has a bucket name, a severity, a recommendation. It is indistinguishable from evidence, and it is not evidence.

The fix is that the field admits a third state:

const versioned =
  versionResult.status === 'fulfilled'
    ? versionResult.value.Status === 'Enabled'
    : null;

And every analyzer that consumes it tests for the observation, not for falsiness:

if (node.versioned === false) { /* finding */ }

null falls through. No finding, because there is nothing to find — only something unread.

The two exceptions are the interesting part

Not every rejection is an absence of information. GetBucketEncryption answers "this bucket has no encryption configuration" by throwing ServerSideEncryptionConfigurationNotFoundError rather than returning an empty body. GetPublicAccessBlock does the same with NoSuchPublicAccessBlockConfiguration. For those two specific error names, the rejection is the fact:

const encrypted =
  encryptResult.status === 'fulfilled'
    ? (encryptResult.value.ServerSideEncryptionConfiguration?.Rules?.length ?? 0) > 0
    : errorName(encryptResult.reason) === 'ServerSideEncryptionConfigurationNotFoundError'
      ? false
      : null;

This is the part you cannot skip by writing a generic "catch everything, return null" wrapper. Two of the four calls encode a real answer in an exception. Collapse all rejections to null and you stop reporting genuinely unencrypted buckets, which is a false negative traded for the false positive you just removed. The error name has to be inspected. There is no way around reading the API's documented behavior call by call.

Four ways absence gets promoted to fact

Once you start looking for this pattern, it shows up everywhere a scan touches an API it does not fully control:

A capped listing. ListBuckets paginates. The old code took the first page and stopped, so accounts past 200 buckets got a partial inventory rendered as a complete one. Nothing downstream can detect a missing bucket — an absent entry reads as "does not exist" to every consumer.

A synthesized node. When code says QueueUrl: process.env.QUEUE_URL, there is no queue name to resolve. A graph node still gets created so the function's edges have somewhere to point, and it was created with hasDLQ: false. The DLQ analyzer read that default as an observation and produced a high-severity finding: a queue literally named unknown had no dead-letter queue. Those nodes now carry placeholder: true, and every analyzer whose evidence is absent configuration skips them:

if (node.type !== 'queue' || node.placeholder) continue;

A failed service. One extractor throwing should not kill an analysis, so each one is wrapped and its outcome recorded rather than only logged. A warning printed to a terminal nobody read is not a signal. The status is one of four values — ok, failed, partial, disabled — and it rides along with the results.

A partial extraction. Sometimes an extractor gets most of what it needed and loses one piece. Throwing away the whole service costs more than it protects; keeping it silently is the exact false negative all of this exists to prevent. PartialExtractionError carries the usable data and the gap, and the source is marked partial.

Why this got urgent

An infrastructure report with a phantom finding wastes an engineer twenty minutes. They open the console, see versioning is already on, shrug, and move on. Annoying, self-correcting.

That was before the reader stopped being human.

Infrawise serves this data to AI coding assistants over MCP, and a model does not shrug. Ask it "which of my buckets are unencrypted" and it gets a JSON array. If the array is empty because the S3 read failed, the model does not infer a failed read. It answers "all your buckets are encrypted" in exactly the tone it uses for things it verified, and then it writes your bucket policy on that assumption. Empty is the most dangerous possible response, because empty is what "everything is fine" also looks like.

So every tool response carries a dataHealth block, and the part that matters here is the source list:

"sources": [{ "service": "s3", "status": "failed", "error": "AccessDenied" }]

Every key is always present. error is null rather than omitted, so nothing has to be inferred from a missing field. get_graph_summary goes further and stamps each node with its own source and sourceStatus, so a node from a degraded source is distinguishable from a clean one without cross-referencing anything.

The rule this gives an assistant is a single sentence, stated in the description of the first tool it is told to call: a source that is not ok means an empty result is "not read", not "none exist". get_table_schema is the sharpest case — with a database listed as failed, found: false means "not looked for", not "no such table". That is the difference between an assistant writing a query against the wrong schema and an assistant telling you to re-run infrawise analyze.

The general shape

If you build anything that reports on infrastructure you do not own — a scanner, a linter, a dashboard, an MCP server — the check is quick. Take any boolean in your output and ask what it holds when the call that fills it fails. If the answer is false, you are shipping a claim you never verified. If the answer is "the whole field is missing", you are asking every consumer downstream to guess, and at least one of them will guess wrong in the direction of "fine".

Three states, always. Observed true, observed false, not observed. The third one costs a nullable type and a few === false comparisons, and it is the entire difference between a report that is trustworthy and a report that is merely quiet.

Infrawise is MIT-licensed and runs locally against your own account: GitHub · npm.

Key takeaways

A boolean that defaults to false on a failed read is asserting something nobody verified. Make the field nullable and have consumers test === false, not falsiness.
Do not wrap every rejection into null blindly. Some APIs answer "not configured" with an exception — GetBucketEncryption and GetPublicAccessBlock both do — and for those, the error name is the fact.
Unpaginated list calls silently shrink your inventory, and a missing item reads as a non-existent item to everything downstream.
Objects synthesized to hold a reference together (from an env var, an ARN, a code path) must be marked as such, or their default values get audited as if they were read from the provider.
If an LLM consumes your output, ship per-source status alongside the data. An empty array with no health signal will be reported to the user as an all clear.

Stale infrastructure context is worse than none

Siddharth Pandey — Sat, 08 Aug 2026 15:06:55 +0000

The bug that isn't a bug

On Tuesday you attach a dead-letter queue to orders-queue. On Wednesday a batch of messages disappears and you ask Claude Code what happened. It answers immediately: orders-queue has no DLQ configured, so failed messages are dropped after the maximum receive count.

That answer is wrong, and it is also not a hallucination. The assistant read a real snapshot of your AWS account. The snapshot was taken Monday.

This is the failure mode that shows up once you give an AI assistant deterministic infrastructure context instead of letting it guess. Guessing produces answers that feel uncertain, and you treat them accordingly. A stale snapshot produces answers that feel authoritative, with real table names, real queue names, real ARNs. Nothing in the response signals that the underlying facts expired.

Infrawise extracts your DynamoDB tables, Lambda configs, queue settings, database schemas, and code-to-table access patterns into a graph, then serves that graph to AI editors over MCP. Everything below is about the part nobody asks for in a feature list: what happens to that graph when it gets old.

Why the context has to be cached at all

The obvious fix is to never cache. Answer every question from a live account read.

That does not survive contact with an actual session. A full infrawise analyze walks every enabled service, paginating through DynamoDB DescribeTable, Lambda configurations and their event source mappings, SQS queue attributes, SNS subscriptions and filter policies, Secrets Manager rotation state, S3 versioning and public-access configuration, ElastiCache clusters, CloudWatch log groups, plus schema introspection against Postgres, MySQL, or MongoDB, plus a local IaC parse, plus an AST scan of the repository. Every extractor is dispatched through a single Promise.all, so wall-clock time is bounded by the slowest one rather than their sum, but it is still seconds, not milliseconds.

An assistant calls get_infra_overview at the start of a task, analyze_function when it opens a handler, get_table_schema before writing a query. Re-extracting the account on each of those calls would make the tools unusable, and it would hammer AWS APIs with describe calls on every keystroke-adjacent action.

So the graph is cached. Which means the graph goes stale. The only real question is whether the tool bounds that staleness and reports it, or lets it drift silently.

What actually expires, and when

The cache is a directory of JSON files under .infrawise/cache, next to your infrawise.yaml. Each entry stores three things: the data, the timestamp it was written, and a cache version.

Reads are TTL-checked, and the check is deliberately blunt:

export function readCache<T>(key: string, maxAgeMs = 3600000): T | null {
  const entry = readEntry<T>(key);
  if (!entry) return null;
  if (entry.version !== CACHE_VERSION) return null;
  if (Date.now() - entry.timestamp > maxAgeMs) return null;
  return entry.data;
}

An expired entry does not return old data with a warning attached. It returns null, which every caller treats as "no cache" and handles by re-analyzing. There is no code path that serves data past its TTL, because a warning is something a caller can ignore and a null is not.

The graph, the findings, and the raw AWS/DB metadata all use the same 24-hour TTL. That number is not arbitrary, and getting there took one bad bug. The metadata cache originally used the function's 1-hour default while the graph used 24 hours. In a long-running serve session, that mismatch meant every graph rebuilt after the first hour came back with an empty metadata half: no table schemas, no Lambda configs, no queue attributes. Findings that depend on that metadata silently stopped being generated. Not an error, not a warning, just fewer findings than an hour ago. The comment in runCodeRefresh still records why the TTLs are now unified:

// Same 24h TTL as the graph cache — a shorter TTL here silently dropped all
// AWS/DB metadata from refreshed graphs once a serve/stdio session passed 1h.
const cached = readCache<CachedMeta>('meta', 24 * 60 * 60 * 1000);

The general lesson is worth stating plainly: when two caches feed one derived result, different TTLs produce a partially-empty result rather than an error. Partial results are the worst kind, because they look like a correct answer to a smaller question.

Refresh happens at the boundary you already have

Both transports share one bootstrap, and it tries the cache first. Running infrawise serve over HTTP, that looks like:

  ✓ Config loaded  infrawise.yaml
  ✓ Cached analysis loaded  42 nodes · 18 edges · 7 finding(s)

If the entries are missing or older than 24 hours, readCache returns null, the bootstrap warns No cache found — running analysis now..., and it re-analyzes before serving a single tool call. You never run a refresh command. Session start is the refresh trigger, because session start is the moment you were already going to wait a few seconds.

When your editor launches infrawise serve --stdio from .mcp.json instead, the same bootstrap runs with its success channel silenced and warnings routed to stderr with an infrawise: prefix — stdout belongs to MCP JSON-RPC, and a stray status line there corrupts the protocol stream.

Inside a session, file saves take a cheaper path. The watcher debounces for 2 seconds, ignores anything outside .ts, .tsx, .js, .jsx, .mjs, and .cjs, and then calls runCodeRefresh, which re-runs the AST scan and the local IaC parse and rebuilds the graph on top of the cached AWS and database metadata. No AWS calls. This is the right trade: the thing that changed when you hit save is your code, not your account. Add a .scan() call to a handler and the scan edge is in the graph on the next debounce tick, without a single describe call leaving your machine. The infrastructure half of that graph is still whatever was cached, bounded by the same 24 hours.

Making age visible instead of silent

Bounding staleness is half the job. The other half is telling the consumer how old the facts are, so it can decide.

get_infra_overview returns a freshness object alongside the actual data:

{
  "analyzedAt": "2026-08-07T09:14:22.019Z",
  "ageSeconds": 98400,
  "stale": true,
  "hint": "Analysis is stale — run `infrawise analyze` to refresh."
}

analyzedAt comes from readCacheTimestamp, a separate read that deliberately ignores the TTL — its whole job is to report age, so applying an expiry to it would defeat the purpose. The stale flag flips past 24 hours, matching the TTL that drives auto-refresh, and the hint field only appears when stale is true.

This exists because the assistant is the one deciding whether to trust the answer. If it is about to tell you a queue has no DLQ, the difference between a 40-second-old graph and a two-day-old one matters, and only the tool knows which one it is holding. Handing over the timestamp costs one field and removes the entire class of confidently-wrong answers described at the top of this post.

When the server boots with no analysis at all, analyzedAt is null and stale is false. Unknown age is reported as unknown rather than as fresh — a null timestamp defaulting to "current" would be exactly the silent lie the field exists to prevent.

Conclusion

Caching infrastructure context is not optional; extraction is far too expensive to run per question. What is optional is whether the staleness that caching creates stays silent. Every design decision here points the same direction: expired reads return null instead of stale data, the two caches that feed one graph share a TTL so they cannot go half-empty, refresh is attached to session start rather than a command you must remember, and the age of the loaded analysis ships as a field in the response so the consumer can weigh it.

If you want the same behavior in your editor, npx infrawise start --claude writes .mcp.json and hands your assistant the graph — GitHub · npm.

Key Takeaways

A stale cache is more dangerous than an empty one, because it produces specific, confident, wrong answers instead of visibly uncertain ones.
Return null past the TTL rather than stale-with-a-warning. Callers ignore warnings; they cannot ignore a null.
When several caches feed one derived result, give them the same TTL. Mismatched TTLs produce silently partial results, which look like correct answers to smaller questions.
Tie refresh to a boundary the user already pauses at — session start — instead of a command they have to remember to run.
Ship the age of your data as a field in the response. The consumer, not the cache, should decide whether 26 hours old is good enough.

Your 12-Minute Frontend Build Is Now Your AI Agent's Bottleneck

Siddharth Pandey — Wed, 05 Aug 2026 07:30:12 +0000

Your coding agent just opened five PRs in a morning. Each one changes a handful of files in one product area. Each one triggers a twelve-minute build of the entire frontend: search, account, admin, marketing pages, all of it. That is an hour of CI to validate maybe two hundred lines, and the review queue is now the slowest part of a workflow you adopted to go faster.

The same twelve minutes used to be an annoyance you absorbed a few times a day. At agent throughput it is the bottleneck.

It gets worse before it gets better. You ask the agent "where does checkout read the pricing config from?" and it opens forty files across four product areas before answering, because as far as the tooling is concerned there is exactly one application and it is enormous. Then it changes six words of copy in the checkout confirmation screen, and every user on the site redownloads a main bundle whose hash moved for reasons that have nothing to do with them.

One build unit, one bundle graph, one context blob. Micro frontends in a monorepo split all three, and the monorepo part is what keeps it from turning into a distributed systems problem you did not sign up for.

The four taxes you are paying

Build fan-out. Your CI has no idea that checkout and search do not touch each other. Any commit invalidates the whole build. Build time is a function of repo size, not change size.

Bundle coupling. Webpack and Vite chunk splitting help with what gets loaded, but not with what gets invalidated. If checkout and search compile into one build output, a checkout change can shift chunk hashes across the app and evict cached bytes users already had.

Delivery coupling. Two teams shipping to the same artifact means every deploy is a merge queue negotiation. The team that is ready waits on the team that is not.

Context cost. This is the newest one and the least discussed. An AI coding agent working in a repo has a finite attention budget. Give it one 1,200-file application with no enforced internal boundaries and it will read broadly, guess about ownership, and occasionally reach into a module it had no business touching. Give it apps/checkout plus three shared libs and it reads less, guesses less, and produces a diff you can actually review.

Splitting without splitting the repo

The mistake people make is equating micro frontends with repo-per-team. That buys you deploy independence and charges you version drift, six duplicate CI configs, and cross-repo refactors that nobody ever does.

Keep one repo. Split the build.

With Nx, scaffolding the pieces is one command. Nx 23 renamed the generators: the app that loads federated modules is a consumer (previously host), the app that exposes them is a provider (previously remote).

nx g @nx/react:consumer apps/shell --bundler=rspack --providerNames=checkout,search
nx g @nx/react:provider apps/account --consumer=shell

The old @nx/react:host and @nx/react:remote generators still ship, so existing workspaces keep working, but new work should use consumer/provider. With the new generators, providers are registered at runtime from an inline list in the consumer's src/mf.ts rather than being frozen into build config.

Each provider gets its own build target and its own deployable output. Underneath, the Module Federation build plugin config looks like this:

import { createModuleFederationConfig } from '@module-federation/enhanced/rspack';

export default createModuleFederationConfig({
  name: 'shell',
  remotes: {
    checkout: 'checkout@https://cdn.example.com/checkout/mf-manifest.json',
  },
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true },
  },
});

singleton: true on React is not optional. Without it you ship two React copies, hooks break across the boundary, and you spend an afternoon on an error message about invalid hook calls that has nothing to do with your hooks.

For remotes that are not known at build time (a plugin surface, a tenant-specific module, an A/B variant), the runtime API takes over:

import { init, loadRemote } from '@module-federation/runtime';

init({
  name: 'shell',
  remotes: [{ name: 'promo', entry: 'https://cdn.example.com/promo/remoteEntry.js' }],
});

const Promo = await loadRemote('promo/Banner');

The performance case, stated honestly

Cache invalidation gets a boundary. Each remote publishes its own entry and its own chunks. A copy change in checkout produces new checkout bytes. Search bytes keep their hashes and stay in the user's cache. On a large app this is the difference between shipping a small delta and making every user re-download a vendor bundle because one hash cascaded.

Loading follows navigation. A remote is fetched when the route that needs it is entered. Users who never open admin never pay for admin. You can approximate this with route-level lazy imports in a monolith, but you cannot approximate the invalidation boundary, and lazy imports quietly re-couple every time someone adds a top-level import for a type.

Local dev stops rebuilding what you are not editing. nx serve shell starts the whole composed app with the remotes built and served statically. Only the remote you are actively editing needs a real dev server, and since Nx 21 you get that by serving the remote itself:

nx serve checkout

On Angular, or on webpack Module Federation without inferred tasks, the equivalent is nx serve shell --devRemotes=checkout.

Now be honest about the costs, because they are real:

Each remote costs a manifest fetch plus an entry fetch. On a route that pulls three remotes, that is latency you did not have before. Preload the manifests for likely-next routes.
Shared singletons only work if versions are compatible. A remote built against React 18 and a host on React 19 fails at runtime rather than at build time, which is the worst place to find out. This is the single biggest operational hazard of the pattern, and it is exactly the failure a monorepo prevents: one lockfile, one version, enforced by the repo rather than by a wiki page.
Below a certain size this is all overhead. One team, a 90-second build, three routes? Do not do this. The pattern earns its place when multiple teams contend for one pipeline.

Where the AI speedup actually comes from

Two mechanisms, both boring, both effective.

Affected-only work. Nx computes a project graph from real imports, so it knows checkout and search are unrelated:

nx affected -t build
nx affected -t test lint

An agent that opens a PR touching only apps/checkout triggers a build of checkout and its dependents. Not the repo. Those five PRs from the opening now cost five checkout builds instead of an hour of full-frontend CI, and they run in parallel because they no longer contend for the same build. The twelve minutes did not get optimized away, it stopped being charged for work that never changed.

Boundaries the agent cannot argue with. Tag every project and let ESLint enforce who may import whom:

'@nx/enforce-module-boundaries': [
  'error',
  {
    allow: [],
    depConstraints: [
      { sourceTag: 'scope:shared', onlyDependOnLibsWithTags: ['scope:shared'] },
      { sourceTag: 'scope:checkout', onlyDependOnLibsWithTags: ['scope:shared', 'scope:checkout'] },
      { sourceTag: 'scope:search', onlyDependOnLibsWithTags: ['scope:shared', 'scope:search'] },
    ],
  },
],

This is the part that changes how it feels to work with an agent. A prompt that says "do not import from other teams' code" is a suggestion the model may or may not follow. A lint rule that fails CI is a fact. When an agent takes the shortcut of reaching into apps/search/src/internal/pricing.ts from checkout, the build tells it no, and it fixes the mistake in the same session instead of you finding it in review three days later.

The context effect compounds. Scoping an agent to one remote plus the shared libs means the files it reads are the files that matter. Smaller context, fewer distractor files, more of the budget spent on the actual change. The same architecture decision that gave you independent deploys gave you a natural unit of work for an agent, which is not a coincidence: both are asking for the same thing, which is a piece of the system you can reason about without loading the rest.

Migration path that does not stall

Do not carve up the whole app. Pick the boundary that hurts most, usually the one where two teams collide in the merge queue, and extract exactly that one.

Create the consumer, keep the existing app as the first provider. Nothing changes for users.
Extract the contended area into a second provider. Shared code goes to libs/shared, tagged scope:shared.
Turn on enforce-module-boundaries in warn mode, fix the violations it finds, then flip it to error.
Switch CI to nx affected. Measure the build time delta before extracting a third remote.

If step 4 does not show a meaningful improvement, stop. You have a dependency-graph problem, not an architecture problem, and adding remotes will not fix it.

Key takeaways

Agent throughput turns a tolerable build time into a hard bottleneck. Five PRs a day made twelve minutes annoying; five PRs an hour makes it the constraint on everything.
Micro frontends buy independent build, cache, and deploy boundaries. A monorepo keeps the single lockfile and single-commit refactors. You want both, not one or the other.
Mark framework packages singleton: true in shared, or hooks break across the remote boundary at runtime.
nx affected -t build turns build time into a function of change size instead of repo size, which is what makes multi-PR agent work practical rather than theoretical.
@nx/enforce-module-boundaries with tags converts your architecture from a convention into a CI failure, and an AI agent respects a failing build far more reliably than a prompt.
Extract one boundary, measure, then decide. Below a couple of teams and a couple of minutes of build time, this pattern costs more than it returns.

Docs worth reading before you start: Nx Module Federation and Module Federation Core.

Your Cognito Login Code Fails Because the App Client Never Allowed That Auth Flow

Siddharth Pandey — Sun, 02 Aug 2026 20:39:22 +0000

Your login screen works locally. You point it at the staging user pool and every sign-in comes back as an error before it ever reaches a password check.

The code your AI assistant wrote calls InitiateAuth with AuthFlow: 'USER_PASSWORD_AUTH'. Reasonable guess: it is the flow in most Cognito tutorials. But the app client in staging was created by a Terraform module that set explicit_auth_flows = ["ALLOW_USER_SRP_AUTH", "ALLOW_REFRESH_TOKEN_AUTH"], and that client also has a secret. So the call fails twice over: the flow is not enabled for this client, and the request is missing SECRET_HASH.

None of that is visible in your source files. The assistant read your repo, found no answer, and produced the most statistically common Cognito snippet on the internet.

The app client is the config, and it is not in your repo

Cognito's failure modes are almost all per app client settings, not per user pool settings. Four of them break generated code immediately:

Allowed auth flows. ExplicitAuthFlows is a whitelist. If ALLOW_USER_PASSWORD_AUTH is not on it, USER_PASSWORD_AUTH is rejected regardless of whether the username and password are correct. Client A in dev may allow it while client B in prod does not, and the same handler code then works in one environment and not the other.

Client secret. A client with GenerateSecret: true requires every auth call to carry SECRET_HASH, a base64 HMAC-SHA256 of username + clientId keyed with the client secret. An assistant that does not know a secret exists will never emit that field, and the call fails on secret verification rather than on credentials.

MFA. With MFA set to ON, InitiateAuth typically returns a ChallengeName and a session instead of tokens. Code written against the happy path reads response.AuthenticationResult.IdToken, gets undefined, and throws somewhere three functions away from the actual cause.

Token validity units. AccessTokenValidity: 60 means nothing on its own. With TokenValidityUnits.AccessToken = 'minutes' it is one hour. With 'days' it is two months. Refresh logic built on the wrong unit either hammers the token endpoint or lets sessions die.

OAuth settings. If you are using the hosted UI instead of direct auth, the client carries its own AllowedOAuthFlows, AllowedOAuthScopes, and CallbackURLs. Build a redirect against a URL that is not in the callback list, or request a scope the client does not allow, and Cognito refuses the request at the authorize endpoint before your app sees anything. An assistant writing the redirect has no way to know the staging client only registered https://staging.example.com/callback while your local dev URL was never added.

Every one of those lives in AWS, not in your repository. Even when the pool is defined in Terraform, the assistant would have to find the right module, resolve the variables, and know which client the running service actually uses. In practice it does not, so it guesses.

Reading the real client config

Infrawise extracts this and hands it to your assistant over MCP. The Cognito extractor in src/adapters/aws/services.ts walks four read-only calls: ListUserPools for every pool, then per pool DescribeUserPool, then ListUserPoolClients, then DescribeUserPoolClient for each client. Both listings are paginated with NextToken, so a pool with 80 app clients does not get silently truncated at the first page.

For each client it keeps exactly the fields that change how you write the call:

clientName, clientId
authFlows          <- ExplicitAuthFlows
oauthFlows         <- AllowedOAuthFlows
oauthScopes        <- AllowedOAuthScopes
callbackUrls       <- CallbackURLs
generatesSecret    <- !!ClientSecret
accessTokenValidity, idTokenValidity, refreshTokenValidity
tokenValidityUnits <- { accessToken, idToken, refreshToken }

Note generatesSecret. DescribeUserPoolClient does return the secret value, and infrawise converts it to a boolean at the point of extraction. The value is never stored in the graph, never cached, and never returned by any tool. Your assistant learns that a secret exists and that SECRET_HASH is mandatory, without ever seeing the secret. Same for users: infrawise never calls any user API. Sign-in code is what it helps you write, not a directory it reads.

The get_cognito_overview MCP tool returns the whole thing:

{
  "total": 1,
  "note": "Client secret values and user data are never included.",
  "userPools": [
    {
      "name": "app-users-staging",
      "id": "ap-south-1_XXXXXXXXX",
      "mfaConfiguration": "OPTIONAL",
      "clients": [
        {
          "clientName": "web-spa",
          "clientId": "4h1...",
          "authFlows": ["ALLOW_USER_SRP_AUTH", "ALLOW_REFRESH_TOKEN_AUTH"],
          "oauthFlows": ["code"],
          "oauthScopes": ["openid", "email"],
          "callbackUrls": ["https://staging.example.com/callback"],
          "generatesSecret": true,
          "accessTokenValidity": 60,
          "tokenValidityUnits": { "accessToken": "minutes" }
        }
      ]
    }
  ]
}

That is the difference between an assistant guessing USER_PASSWORD_AUTH and an assistant writing SRP with a SECRET_HASH, because the whitelist and the secret flag are sitting right there in its context.

The tool description registered in src/server/index.ts tells the model when to reach for it and when not to: call it before writing any sign-in, sign-up, or token-refresh code; do not call it to look up users or tokens. That last clause matters more than it looks. Tool descriptions are the only thing steering which tool an agent picks, and a tool that sounds like a user directory will get called for the wrong reasons.

Turning it on

Cognito is off by default. infrawise start writes an infrawise.yaml with cognito: { enabled: false }, because most repos have no Cognito and there is no reason to make an API call for them. Auth work means flipping one key:

cognito:
  enabled: true

The IAM policy is four read actions, and nothing else:

cognito-idp:ListUserPools
cognito-idp:DescribeUserPool
cognito-idp:ListUserPoolClients
cognito-idp:DescribeUserPoolClient

Then:

infrawise start --claude

That probes your environment, runs the analysis, writes .mcp.json so your editor reconnects on every future launch, and opens Claude Code with all 21 tools available. From then on you just run claude. Results are cached for 24 hours, and get_infra_overview reports a freshness object with the analysis age and a stale flag so the assistant can tell when it is looking at yesterday's picture.

Ask "write me a sign-in handler for the staging pool" and the flow is no longer a guess. The assistant calls get_cognito_overview, sees ALLOW_USER_SRP_AUTH and generatesSecret: true, and writes SRP with a secret hash the first time.

What this actually buys you

The bug class here is boring, which is why it eats so much time. Nothing crashes at build time. Types are fine. Tests that mock the Cognito client pass. The failure only shows up against a real user pool, as an exception whose message is about a flow name rather than about the app client that disallowed it, and the fix is a config value you have to go read in a console tab.

Cognito is one instance of the general pattern. The information needed to write correct code is split between your repo and your cloud account, and the assistant only has half. Infrawise closes that gap deterministically: no LLM in the extraction path, just SDK calls, AST parsing, and rule-based analyzers producing a graph that MCP tools read from.

Try it: GitHub or npm.

Key takeaways

Cognito failures are per app client, not per user pool. The same code succeeds against one client and fails against another in the same pool.
Check callbackUrls and oauthScopes before building a hosted UI redirect. A URL that is not registered is rejected at the authorize endpoint.
If generatesSecret is true, every auth call needs SECRET_HASH. An assistant that does not know a secret exists will never emit it.
AccessTokenValidity is meaningless without TokenValidityUnits. 60 is an hour or two months depending on the unit.
Set cognito: enabled: true in infrawise.yaml (it defaults to false) and grant the four cognito-idp read actions.
Call get_cognito_overview before writing sign-in, sign-up, or refresh code. It never returns client secret values or user data.

Your Lambda Passes Tests Then Throws AccessDeniedException in Production

Siddharth Pandey — Mon, 27 Jul 2026 06:12:56 +0000

You asked Claude Code to add a step to your order handler: pull the Stripe key out of Secrets Manager, then publish an order.settled event to SNS. It wrote clean code. Your unit tests mock both SDK clients, so they pass. CI is green. You deploy.

Then the first real invocation logs this:

AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/order-processor-role/order-processor
is not authorized to perform: sns:Publish on resource: arn:aws:sns:us-east-1:123456789012:order-events

Nothing was wrong with the code. The execution role was written months ago, when the function only touched DynamoDB. The code grew a new dependency and the policy did not follow.

This is one of the most annoying classes of AWS bug because it is invisible to every tool in the loop. The type checker sees a valid PublishCommand. The linter sees valid TypeScript. The AI assistant reads your handler and has no idea what order-processor-role allows, because the policy lives in AWS (or in a Terraform file three directories away), not in the file it is editing.

Infrawise closes that gap by comparing the two directly. GitHub · npm

Why the assistant cannot see this on its own

An AI coding assistant works from the files you give it. When it writes a Lambda handler, it can see:

the handler source
imports, so it knows which AWS SDK clients you use
maybe a nearby test file

What it cannot see is the runtime identity that code will execute as. The link between "this handler" and "this IAM role" is a Role property on the deployed function, resolved through an ARN, and the policy behind that ARN is a set of JSON documents attached to a role name. Three lookups away from anything in your repo.

So the assistant does the only thing it can: it assumes the permissions exist. Ninety percent of the time they do, which is exactly what makes the other ten percent expensive. The failure surfaces at runtime, in an environment where you are reading CloudWatch instead of your editor.

What infrawise actually compares

Infrawise already builds a graph of your infrastructure and your code. The AST scan produces typed edges from functions to the things they touch: a query or scan edge to a DynamoDB table, a reads_secret edge to a Secrets Manager secret, a reads_parameter edge to an SSM parameter, a publishes_to edge to an SQS queue or an SNS topic.

Separately, the Lambda extractor pulls roleArn off every function, then fetches what that role permits. It batches the fetch per unique role ARN, so ten functions sharing one role cost one IAM round trip, not ten. For each role it walks both attached managed policies and inline policies, decodes the policy documents, and reduces every Allow statement to the service prefix of its actions. sns:Publish becomes sns. dynamodb:GetItem becomes dynamodb. A bare "*" action becomes *.

The result is allowedServices, a flat list like ["logs", "dynamodb"].

Now the comparison is trivial. Walk the function's outgoing edges, map each to the service prefix it requires, and subtract allowedServices. What is left is what the code needs and the role does not grant.

The mapping is deliberately narrow. Five edge types map to five services:

Edge	Required service
`query` or `scan` on a DynamoDB table	`dynamodb`
`reads_secret`	`secretsmanager`
`reads_parameter`	`ssm`
`publishes_to` a queue	`sqs`
`publishes_to` a topic	`sns`

Two cases produce no finding at all, on purpose:

No IAM data. If the IAM read fails (missing permission, SCP, whatever), allowedServices comes back undefined and the analyzer skips the function entirely. Infrawise will not tell you a permission is missing when it could not read the policy. Silence beats a false alarm you learn to ignore.

Wildcard. If the role has "Action": "*" anywhere, the service list contains * and the function is skipped. AdministratorAccess is its own problem, but it is not a missing-permission problem.

Where you see it

Two places, and they cover the two moments where it matters.

While you are writing the handler. analyze_function returns missingPermissions alongside everything else it knows about the function:

{
  "function": "order-processor",
  "found": true,
  "file": "src/handlers/order-processor.ts",
  "triggers": [
    { "type": "sqs", "source": "orders", "eventShape": "event.Records[0].body" }
  ],
  "accesses": [
    { "targetId": "table:dynamo:Orders", "edgeType": "query", "targetName": "Orders", "targetType": "table" },
    { "targetId": "secret:aws:stripe/live", "edgeType": "reads_secret", "targetName": "stripe/live", "targetType": "secret" },
    { "targetId": "topic:aws:order-events", "edgeType": "publishes_to", "targetName": "order-events", "targetType": "topic" }
  ],
  "missingPermissions": ["secretsmanager", "sns"],
  "issues": [ ... ],
  "recommendations": [ ... ]
}

That is the whole point. The assistant asked one question before writing code and got back the trigger event shape and the fact that two of the three services this function talks to are not in its role. It can tell you to fix the policy in the same breath as it writes the handler.

Note the field is omitted entirely when IAM data was unavailable, rather than returned as an empty array. An empty missingPermissions means "checked, nothing missing." An absent one means "not checked." Those are different answers and conflating them is how you get misplaced confidence.

Before you deploy. The same comparison runs as a high-severity analyzer in infrawise analyze and infrawise check:

  1.  HIGH   Lambda "order-processor" accesses sns but execution role has no sns permissions
       "order-processor" calls sns in code but its IAM execution role (arn:aws:iam::123456789012:role/order-processor-role) has no sns:* permissions. This will cause AccessDeniedException at runtime — code passes tests but fails in AWS.
       → Add sns permissions to the execution role for "order-processor". Minimum required: sns:Publish.

The recommendation names actual actions, not sns:*. Each service has a minimal action set baked in: secretsmanager:GetSecretValue for secrets, ssm:GetParameter, ssm:GetParameters, ssm:GetParametersByPath for parameters, sqs:SendMessage, sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes for queues, and the CRUD-plus-query set for DynamoDB. You can paste the list into the policy without thinking about whether you just granted dynamodb:DeleteTable.

Because it is a high-severity finding, infrawise check fails the build on it by default. That is the whole CI story: check runs a fresh analysis (never a cached graph, since CI gating on stale data is worse than no gating) and exits non-zero when anything at or above --fail-on shows up. Default threshold is high.

infrawise check

Two things to know before you trust it

Names have to line up. The check joins a code function node to a Lambda node by exact name match. If your handler is exported as handler in src/orders.ts but deployed as order-processor, infrawise finds no code node for that Lambda and produces no finding. It fails closed, which is the right direction, but it means the check is only as good as your naming discipline. If you use a framework that derives function names from the deployed name, you get this for free.

Granularity stops at the service prefix. Infrawise compares sns against sns, not arn:aws:sns:us-east-1:123456789012:order-events against the resource in your PublishCommand. A role scoped to one topic passes the check even if your code publishes to a different topic. So this catches "the policy has no SNS at all," which is the common case, not "the policy has the wrong SNS resource." Resource-level checking is a different problem and pretending otherwise would make the finding untrustworthy.

It needs read access to IAM. Five actions: iam:ListAttachedRolePolicies, iam:ListRolePolicies, iam:GetRolePolicy, iam:GetPolicy, iam:GetPolicyVersion. They are optional in the infrawise IAM policy. Drop them and everything else still works, you just lose this check. Infrawise is read-only across the board, so nothing here writes to your account.

Try it

cd your-project
npx infrawise start --claude

That probes your environment, writes infrawise.yaml and .mcp.json, and opens Claude Code with all 21 tools connected. Ask it to write a Lambda that reads a secret, and watch it check the role before it writes the code.

GitHub · npm

Key takeaways

AccessDeniedException in a Lambda is almost never a code bug. It is a drift bug: the code grew a dependency, the execution role did not follow.
Your AI assistant cannot catch this from source files alone, because the role that code runs as is three lookups away from anything in your repo.
Infrawise compares the function's actual outgoing edges (DynamoDB query, secret read, SSM read, SQS send, SNS publish) against the service prefixes its IAM role permits, then reports the difference.
Call analyze_function before writing a handler to get missingPermissions alongside the trigger event shape. An absent field means IAM was not readable; an empty array means it was checked and clean.
Run infrawise check in CI. Missing permissions are high severity, so the default --fail-on high blocks the deploy.
The check is service-level, not resource-level, and joins code to Lambda by exact function name. Know both limits so you know what a clean result actually proves.

How I Solved Claude Code Silently Missing the SQS Trigger on My Lambda

Siddharth Pandey — Wed, 22 Jul 2026 19:50:35 +0000

I asked Claude Code to add a handler for processOrders, a Lambda wired up to consume from orders-queue and read the matching row out of the Orders DynamoDB table. It wrote one immediately — confidently, in one shot, the way it writes most things.

It also parsed the event body wrong.

The problem: Claude Code didn't know the Lambda had an SQS trigger

processOrders is invoked by orders-queue through an event source mapping — that's not in processOrders's source file, it's in the AWS account. Claude Code, reading only the handler's code, had no way to see that mapping. So it guessed at the event shape instead of knowing it, and reached for event.body — the shape you'd expect from an API Gateway proxy integration, not from SQS. The actual shape for an SQS-triggered Lambda is event.Records[0].body. First message in, first field access, and the handler throws.

That wasn't the only thing invisible from source alone:

orders-queue has no dead-letter queue. If the handler throws, SQS retries up to maxReceiveCount times and then discards the message — no alert, no queue-depth spike, nothing in the logs pointing at what happened. A failed order just vanishes.
The Orders table has one partition key (orderId) and zero GSIs. Any lookup by anything else becomes a full table scan the moment the handler ships.

None of that is visible from reading processOrders's current code. It's the state of the AWS account, and an AI assistant reading only source files fills the gap with a plausible guess instead of a fact — starting with which trigger the function even has.

The fix: infrawise's MCP tools in the loop, in order

Here's what the same session looked like once I wired infrawise into Claude Code as an MCP server and asked it to redo the handler.

Start wide: get_infra_overview. No arguments, just a snapshot — table names, queue names, lambda count, high-severity findings. It comes back showing the Orders table, orders-queue, and processOrders already in the graph, plus a high-severity finding already attached to that Lambda. That finding surfaces before the handler is written, not after the deploy.

Narrow to the function: analyze_function. Called with function: "processOrders", this is the tool built for "I'm about to write or review this handler," and it returns four things Claude Code would otherwise guess at:

The trigger event shape. processOrders is triggered by SQS, so the correct shape is event.Records[0].body — not event.body. Infrawise keeps a fixed map per trigger type (SNS is event.Records[0].Sns.Message, S3 is event.Records[0].s3.object.key, DynamoDB Streams is event.Records[0].dynamodb.NewImage), so the entry point is right on the first draft.
The DLQ finding, made concrete. Infrawise's LambdaMissingTriggerDLQAnalyzer walks every Lambda's SQS/Kinesis/DynamoDB-stream triggers, checks whether the source queue has a DLQ, and raises high severity when it doesn't: "processOrders is triggered by orders-queue which has no DLQ — if the Lambda handler fails, messages will be retried and eventually discarded with no failure record." Same problem named in the previous section, now attached to the exact function and queue instead of being a fact nobody checked.
Missing IAM permissions. When execution-role data is available, analyze_function diffs what the function's code actually calls against what its role allows, and returns the gap — catching an AccessDeniedException before it happens in prod instead of after.
Deduplicated recommendations, collapsed into one list instead of several warnings to reconcile by hand.

Confirm the queue directly: get_queue_details. The handler's retry behavior depends on more than DLQ presence, so Claude Code checks the queue itself: hasDLQ: false confirmed, plus visibility timeout, encryption, and isFifo. That last field matters more than it looks — if the queue were FIFO, every SendMessage call in the handler would need a MessageGroupId, and skipping it isn't a lint warning, it's a runtime error the first time the handler publishes.

Get the schema right: get_table_schema. Called with tables: ["Orders"], this returns the partition key (orderId), billing mode (PAY_PER_REQUEST), and the fact that there are no GSIs. If the handler needs to look up an order by anything other than orderId, that's a Scan, and infrawise's scan analyzer flags it the moment it lands in the code graph — so Claude Code reaches for suggest_gsi up front instead of shipping the scan and fixing it in the next PR. Row data is never included — column names, types, keys, and index definitions only, and only for the tables this handler actually touches, not the whole account's schema dumped into the prompt.

What shipped instead

With all four calls back, the rewritten handler:

Parses event.Records[0].body — the correct shape for this trigger, not a guess
Queries Orders by orderId — no scan, because the schema call already ruled that out
Ships with an explicit callout that orders-queue needs a DLQ before this goes to production
Doesn't publish anywhere without checking isFifo first

Every one of those four things was either wrong or invisible in the first version — the one Claude Code wrote from source files alone. None of it required me to open the AWS console mid-task or remember which table has which GSI.

Why this is a repeatable pattern, not a one-off

The four tools compose in a fixed order because each answers a narrower question than the last: get_infra_overview says what exists, analyze_function says what's wrong with the one thing being touched, get_queue_details and get_table_schema fill in the operational and schema detail neither of the first two carries at full resolution. That's the same shape as infrawise's own "reviewing an entire service" and "before writing a query" patterns — it holds for any handler, not just this one.

None of this runs an LLM against the infrastructure. Extraction and analysis are deterministic — AST parsing, live AWS reads, rule-based analyzers, graph correlation. Claude Code only consumes that graph through MCP, the same way it consumes source files. The difference is the graph doesn't guess.

Try it in your own project — npx infrawise start --claude writes the .mcp.json and opens Claude Code with all 21 tools wired in, no server to babysit. GitHub · npm

Key takeaways

Call analyze_function before writing or reviewing any Lambda handler — it returns the correct trigger event shape, missing IAM permissions, and any DLQ/trigger findings in one call.
A queue with a live SQS trigger and no DLQ is a high-severity finding for a reason: failed messages are retried up to maxReceiveCount times, then discarded with no record.
Check isFifo on any queue before writing SendMessage calls — a missing MessageGroupId on a FIFO queue is a runtime error, not a style issue.
Use get_table_schema with just the tables a handler touches instead of dumping the whole schema into the prompt — it also tells you whether the GSI your query needs already exists.
None of this requires an LLM to analyze your infrastructure — the graph is deterministic; Claude Code only reads it.

Your Lambda List Was Silently Truncated at 200 — And Your AI Assistant Never Knew

Siddharth Pandey — Mon, 20 Jul 2026 15:01:08 +0000

Hook

An AWS account with 240 Lambda functions runs infrawise analyze. The tool prints a clean summary: services detected, findings generated, no errors. A developer asks their AI assistant, wired up through MCP, "does this function have a dead-letter queue?" for a function that happens to be function #217 in the account. The assistant calls get_lambda_overview, gets back a list, doesn't find the function, and confidently tells the developer it doesn't exist — or worse, silently skips it and reasons about a different function with a similar name. No error. No warning. Just a wrong answer delivered with total confidence, because 40 functions never made it into the graph in the first place.

That was Infrawise issue #40, and it's a useful case study in how a tool whose entire pitch is "stop AI assistants from guessing" can quietly start guessing itself.

The 200-function wall

Infrawise builds an in-memory graph of a project's infrastructure — tables, functions, queues, indexes — and exposes it to AI coding assistants through 21 MCP tools. extractLambdaMetadata in src/adapters/aws/services.ts is the function responsible for pulling every Lambda function into that graph. It calls AWS's ListFunctionsCommand in pages of 50 and loops until AWS says there's nothing left:

do {
  const res = await client.send(new ListFunctionsCommand({ Marker: marker, MaxItems: 50 }));
  // ...push each function into the array...
  marker = res.NextMarker;
} while (marker && functions.length < 200);

That trailing && functions.length < 200 is the whole bug. Once the running total hit 200 — four pages in — the loop stopped, even though AWS was still handing back a NextMarker and had more functions to give. There was no error, no thrown exception, no log line. The function just returned early with a partial list and reported success.

For a small project this never surfaces. Most side projects don't have 200 Lambda functions. But "common in larger orgs," as the issue itself puts it, is exactly the audience infrawise is trying to win — teams with enough infrastructure that pasting schemas into a prompt every session actually hurts. Those are the accounts most likely to hit the cap, and the ones with the least tolerance for a tool that quietly drops data.

Why silent is worse than wrong

Infrawise's own docs describe two pillars: Context — give the AI assistant your real schema instead of making the developer paste it — and Guard — catch expensive infrastructure mistakes before they ship. The 200-function cap broke both, and it broke them without telling anyone.

Every function past the cap disappeared from the graph entirely — no node, no edges, nothing for the graph engine to attach event-source mappings, IAM roles, or trigger metadata to. Three consumer paths inherited that gap directly:

LambdaMissingTriggerDLQAnalyzer — the analyzer that flags Lambda triggers with no dead-letter queue — silently produced zero findings for those functions. Not "skipped, see warning." Zero findings, same as a function that's perfectly configured.
analyze_function, the MCP tool an AI assistant calls before writing or reviewing a handler, would report no issues for a function it never saw, rather than saying it didn't have data.
get_lambda_overview, the tool that lists every function's runtime, memory, timeout, and triggers, just wouldn't include the function in the list at all.

None of these paths distinguish "checked and found nothing wrong" from "never checked." That distinction is the entire value proposition of a deterministic tool. Infrawise's pitch, explicit in its own docs, is that it doesn't use an LLM to analyze infrastructure — everything is AST parsing, schema introspection, and rule-based analyzers, specifically so an AI assistant gets ground truth instead of a guess. A silent truncation at 200 functions turns that ground truth into a guess anyway, just one dressed up as certainty.

A pattern, not a one-off

The 200-function cap wasn't an isolated mistake — it's one of several bugs in Infrawise's own issue tracker that share the same shape: a limit or a stale value fails quietly instead of loudly.

Issue #45 found that CACHE_DIR was computed from process.cwd() at module load time, so running infrawise analyze from one directory and the MCP server from another meant the second command silently read a cache built for a different invocation path — no mismatch warning, just answers that looked current and weren't. Issue #38 found that --no-cache was accepted by the CLI parser but never actually read by runAnalyze, so a developer explicitly asking for a fresh scan got a cached one anyway, with no indication the flag had been ignored. And issue #39 found that LambdaMissingTriggerDLQAnalyzer was wired into the one-time infrawise analyze path but missing from runCodeRefresh, the path the file watcher calls on every save — so DLQ findings that showed up on the first run quietly vanished after the first edit, with the developer none the wiser.

Different subsystems, same failure mode: nothing crashed, nothing logged, the tool just answered with less than it should have and gave no sign of it. For a tool that stakes its value on being more trustworthy than an LLM's guess, "wrong but confident" is the one failure mode it can't afford — and it's the one that shipped three separate times before anyone caught it.

The fix

The fix for #40 was a one-line diff:

- } while (marker && functions.length < 200);
+ } while (marker);

Pagination now runs until AWS says there's nothing left, full stop. The fix direction noted in the issue also called for a warning log if pagination ever gets cut short for another reason — worth keeping in mind if you're building a similar extraction loop: an arbitrary safety cap on a paginated API call is rarely wrong to have, but silence when it triggers always is. A logger.warn costs one line and turns a silent data gap into a debuggable one.

If you're pointing an AI assistant at your own AWS account and it has more than 200 Lambda functions, this fix landed in the same release cycle as the other three — worth confirming you're on a current version.

GitHub · npm

Key Takeaways

A pagination cap with no warning is a silent data-loss bug waiting for an account large enough to trigger it — 200 felt generous until "larger orgs" turned out to be the target audience.
Distinguish "checked and found nothing" from "never checked" in any analyzer or query result — collapsing them into the same empty response is the failure mode that erodes trust fastest.
Audit every loop bounded by both a natural termination condition (a pagination marker) and an arbitrary one (a hardcoded count) — the arbitrary one is usually the one that fails silently.
Cache keys derived from process.cwd() or other invocation-time state can go stale in ways a static cache TTL never catches — tie cache identity to something stable, not to where the process happened to start.
If a CLI flag exists, verify the code path actually reads it. --no-cache sitting in the parser but unused is exactly the kind of gap that only turns up when someone reads the issue tracker, not the tests.

The Right Way to Start Claude Code on an AWS Project

Siddharth Pandey — Tue, 14 Jul 2026 09:40:36 +0000

You know the drill for adding an MCP server to a project: dig the exact command string out of the docs, hand-write a .mcp.json with an absolute path you'll typo once, restart the editor, and discover no tools showed up because the server expected a config file you haven't created yet. Plenty of MCP servers lose their would-be users somewhere inside that loop.

Infrawise collapses the whole loop into one command. It's an open-source tool (npm) that statically analyzes your codebase, AWS infrastructure, and database schemas, then exposes that context to AI coding assistants over MCP — so Claude Code knows your actual partition keys, GSIs, and indexes instead of guessing from source files. This post is about the part that usually kills tools like this before they deliver any value: setup.

Section 1: One command, four steps

npm install -g infrawise   # or skip install and use npx
cd your-project
infrawise start --claude

start does four things, in order:

1. Probes your environment. If there's no infrawise.yaml in the project, it generates one. It reads AWS_PROFILE if set; otherwise it looks at your configured AWS profiles — one profile means zero questions, several means one prompt asking which to use. That's the entire interview. (If you want the full guided wizard instead, infrawise start --interactive runs it.)

2. Runs the analysis. It scans your AWS services, database schemas, and codebase, builds a graph of services, tables, indexes, and query patterns, and runs rule-based analyzers over it. No LLM is involved in this step — extraction and analysis are deterministic, so the same infrastructure always produces the same graph.

3. Writes .mcp.json to your project root. This is the file you'd otherwise write by hand:

{
  "mcpServers": {
    "infrawise": {
      "command": "infrawise",
      "args": [
        "serve",
        "--stdio",
        "--config",
        "/absolute/path/to/infrawise.yaml"
      ]
    }
  }
}

4. Opens Claude Code. Claude Code reads .mcp.json automatically and starts the session with all 21 infrawise tools available — schema lookups, per-function analysis, GSI suggestions, queue and topic details, the lot.

If the claude CLI isn't installed, start tells you exactly that and where to get it, instead of failing silently.

Section 2: Day two — you never type `infrawise` again

This is the part that matters more than the first run. .mcp.json doesn't point at a long-running server you have to remember to start. It tells the editor how to spawn one: every time you launch Claude Code in that project, the editor itself runs infrawise serve --stdio as a child process. There is no port to keep free, no background daemon to babysit, no "is the server running?" debugging session.

So the second-day workflow is:

claude

That's it. No infrawise command anywhere.

Two mechanisms keep the context from going stale underneath you:

A 24-hour analysis cache. The analysis from start is cached. When the editor spawns the server and the cache is fresh, the session begins instantly with the existing graph. Once the cache is older than 24 hours, the next session start refreshes it. The freshness is also visible to the assistant itself: get_infra_overview returns an analyzedAt timestamp, an ageSeconds value, and a stale flag, so Claude can tell you — or decide on its own — when the picture it has is old. (This came out of a reader question on an earlier post about deterministic analysis; it shipped as a proper feature.)

A file watcher inside the session. While the server is running, it watches the repository for file changes and re-runs code analysis on save. Write a new function that calls DynamoDB.scan() mid-session, and the code graph reflects it — you don't need to restart anything for the assistant to see what you just wrote.

Infrastructure changes are the one thing that won't propagate automatically mid-session — if you just added a table or changed a GSI in AWS, run infrawise analyze to force a full re-scan rather than waiting out the cache. And if the config itself has drifted from reality (new AWS account, different profile), infrawise start --rediscover deletes infrawise.yaml and the .infrawise/ cache directory and rebuilds both from scratch.

Section 3: Not a Claude Code shop? Same command, different flag

The --claude flag is one of three editor targets, and none of them changes what gets analyzed — only where the MCP config lands:

infrawise start --cursor writes .cursor/mcp.json and opens Cursor.
infrawise start --vscode writes into .vscode/mcp.json and opens VS Code. This one merges rather than overwrites: if you already have other MCP servers registered in that file, they survive. Infrawise adds its own entry alongside them.
infrawise start with no flag writes .mcp.json, prints the launch command for each editor, and exits — for any other MCP-capable editor, point it at infrawise serve --stdio --config /path/to/infrawise.yaml.

And for the teammates who don't use an AI editor at all, the same analysis runs as a CI gate:

infrawise check --fail-on high

check runs a fresh analysis and exits non-zero when any finding reaches the threshold severity (high is the default; medium and low tighten it). A full-table scan on a production DynamoDB table fails the build whether or not anyone on the team has ever opened Claude Code.

Section 4: What the assistant actually does with it

The payoff for the setup being this short is that the context is there before you need it. Without it, an AI assistant reading only your source files will happily suggest a .scan() on a table with 50 million rows, or recommend adding a GSI you already have. With the MCP tools connected, it can call get_table_schema for the exact columns and keys, analyze_function for a Lambda's real trigger event shape, or suggest_gsi for a ready-to-use index definition matched to your table's billing mode — before writing the query, not after you've reviewed it.

I've written about those analysis capabilities in earlier posts; the point of this one is narrower. A context tool only works if it's actually connected, and "actually connected" has to cost less than the problem it solves. Pasting a schema into a prompt costs thirty seconds, every session, forever. infrawise start --claude costs one command, once.

Conclusion

The gap between "this MCP server exists" and "this MCP server is running in my editor" is where most infrastructure context tools die. Infrawise's answer is to make the editor own the server lifecycle: one start command probes, analyzes, writes the editor config, and launches; from then on the editor spawns infrawise serve --stdio itself, a 24-hour cache keeps session starts instant, and a file watcher keeps the code graph current while you work.

Try it on a real project — the first start on an actual AWS account is where it gets interesting: GitHub · npm

Key Takeaways

infrawise start --claude is the entire setup: probe environment, generate infrawise.yaml, analyze, write .mcp.json, open Claude Code with 21 MCP tools.
After the first run, just launch your editor — it spawns infrawise serve --stdio from .mcp.json on its own. No daemon, no port, no second command.
Analysis is cached for 24 hours and refreshed at session start when stale; the assistant can check freshness itself via get_infra_overview.
File changes are picked up mid-session by a watcher; infrastructure changes need infrawise analyze, and --rediscover rebuilds config from scratch.
--cursor and --vscode target other editors (the VS Code writer merges with existing MCP servers), and infrawise check --fail-on high gates CI with the same analysis.

Why SNS Silently Drops Your Messages and How to Catch It Before You Ship

Siddharth Pandey — Sat, 11 Jul 2026 08:53:46 +0000

Your checkout service publishes an OrderRefunded event to an SNS topic. The publish call returns a MessageId. No exception, no retry, nothing in the dead-letter queue. Three days later a customer emails asking where their refund is, and you discover the refund Lambda was never invoked.

The message wasn't lost. It was filtered. One of the topic's subscriptions has a filter policy that requires an eventType message attribute, and your publish call didn't include it. SNS did exactly what it was configured to do: it evaluated the filter, found no match, and skipped delivery for that subscription. From the publisher's side, everything looks like success.

This is one of the nastiest failure modes in event-driven AWS architectures, because every tool you'd normally reach for reports green. This post walks through why it happens, why neither your code review nor your AI coding assistant can catch it from source code alone, and how to make the contract visible at coding time instead of incident time.

The contract nobody wrote down

SNS filter policies live on the subscription, not the topic. A subscriber says "only deliver messages where the eventType attribute is one of these values":

{
  "eventType": ["order.refunded", "order.cancelled"]
}

For that subscription to ever receive anything, the publisher must include the attribute:

await sns.send(
  new PublishCommand({
    TopicArn: process.env.ORDER_EVENTS_TOPIC,
    Message: JSON.stringify(refund),
    MessageAttributes: {
      eventType: { DataType: 'String', StringValue: 'order.refunded' },
    },
  }),
);

Omit MessageAttributes and the publish still succeeds — SNS accepts the message and returns a MessageId regardless of whether any subscription matches. The message simply isn't delivered to the filtered subscription.

Three things make this failure quiet:

No error surface. A filter mismatch is not a delivery failure. The subscription's redrive policy never kicks in, so the message never lands in a DLQ. There is nothing to retry and nothing to alert on by default.
The only trace is a metric. SNS increments a NumberOfNotificationsFilteredOut CloudWatch metric, but unless you already suspect filtering, nobody looks at it — and by the time you do, you're debugging in production.
Tests pass. Unit tests mock the SNS client and assert that PublishCommand was called. The mock has no filter policy. The gap between your code and the subscription's configuration is exactly the part the test can't see.

There is a second variant of the same trap: filter policies can also match against the message body (FilterPolicyScope: MessageBody) instead of message attributes. Then the required keys must appear in your JSON payload itself. Same silence, different location.

Why your AI assistant writes the broken version

Ask an AI coding assistant to "publish an order refunded event to the order-events topic" and it will produce a perfectly reasonable PublishCommand call — topic ARN from an environment variable, JSON.stringify on the payload, maybe a comment. What it will almost never produce is the MessageAttributes block with exactly the keys your subscriptions filter on.

It can't. The filter policy is not in your repository. It's a JSON document attached to a subscription in your AWS account, set by whoever wired up the consumer — possibly you, six months ago. The assistant reads your source files, sees other publish calls (which may themselves be missing attributes), and generates code that matches the pattern it found. If the pattern is wrong, the wrongness propagates.

The manual fix is miserable: open the AWS console, navigate to the topic, open each subscription one by one, read each filter policy, and paste the required attribute names into your prompt. Every session. For every topic. This is the copy-paste loop that breaks flow — and if you skip it once, you ship the silent drop.

Pulling the contract into the coding session

This is the problem infrawise is built for: it extracts your live infrastructure into a graph and serves it to your AI assistant over MCP, so the assistant queries facts instead of guessing.

cd your-project
npx infrawise start --claude

That analyzes your AWS account and codebase, writes .mcp.json, and opens Claude Code with 21 MCP tools connected. For SNS specifically, the extraction is read-only and direct: infrawise lists your topics, then for every confirmed subscription fetches its attributes, parses the FilterPolicy JSON, and records which attribute keys the policy requires and whether the policy scope is MessageAttributes or MessageBody.

The result is exposed through a tool called get_topic_details. For each topic it returns the subscription count, encryption status, and a filterPolicies array:

{
  "name": "order-events",
  "provider": "aws",
  "subscriptionCount": 3,
  "encrypted": true,
  "filterPolicies": [
    {
      "subscriptionArn": "arn:aws:sns:...:order-events:a1b2...",
      "protocol": "sqs",
      "requiredAttributes": ["eventType"],
      "scope": "MessageAttributes"
    }
  ]
}

Now the workflow changes. When you ask your assistant to write a publish call, it calls get_topic_details first, sees that a subscription on order-events filters on eventType, and writes the MessageAttributes block into the code on the first attempt. The contract that used to live invisibly in a subscription's configuration is now part of the context every generated publish call is checked against.

The tool description itself tells the assistant when to use it — before writing any SNS publish code — so you don't have to remember to prompt for it. And because infrawise also scans your application code (an AST pass that recognizes PublishCommand, PublishBatchCommand, and SDK publish calls and resolves their target topic ARNs), the graph knows which of your functions publish to which topics. Reviewing an existing publisher works the same way: the assistant can cross-reference what the function sends against what the topic's subscriptions require.

A few boundaries worth stating, because tools that read your AWS account should be explicit about them. Infrawise is read-only — the SNS extraction uses GetTopicAttributes, ListSubscriptionsByTopic, and GetSubscriptionAttributes, nothing that writes. It never reads message contents, secret values, or parameter values. And the analysis is deterministic: AST parsing and API introspection, no LLM deciding what your infrastructure looks like. The LLM is only a consumer of the extracted context.

Conclusion

Silent message drops are a configuration-versus-code mismatch, and those never show up in the layer you're staring at. The filter policy is correct. The publish code is correct. Only the combination is broken, and the combination exists nowhere in your repository — until you put it there.

You can do that manually every session by reading subscriptions in the console, or you can have it extracted once and served to your assistant automatically. If you're on the second option: GitHub · npm — npx infrawise start --claude and ask your assistant what the order-events topic requires.

Key Takeaways

An SNS publish that misses a subscription's filter policy succeeds silently: MessageId returned, no DLQ entry, no error. The redrive policy only covers delivery failures, and a filter mismatch isn't one.
The publisher's contract lives on the subscription, in AWS, not in your code — so tests with mocked SNS clients and AI assistants reading source files both miss it.
Check FilterPolicyScope: policies can require message attributes or keys in the message body. The fix is different for each.
Before writing any publish call, enumerate the target topic's filter policies and include every required attribute. With infrawise, get_topic_details gives your AI assistant that list automatically.
The NumberOfNotificationsFilteredOut CloudWatch metric is your post-hoc signal, but the goal is to never need it — catch the missing attribute at coding time.

Stop Sending Your AI Assistant 40 Tables When It Only Needs 3

Siddharth Pandey — Tue, 07 Jul 2026 08:35:15 +0000

Say your service has 40 tables. You ask Claude Code to fix a bug in checkout — a function that touches exactly three of them: orders, payments, inventory_reservations. If your MCP server hands the model your whole schema graph on every call just to answer that, you've spent a few thousand tokens of context on 37 tables nobody asked about, before the model has written a single line of code.

Multiply that by every tool call, every session, every developer on the team, and "just give it the schema" turns into a real line item — slower responses, a noisier context window, and a model more likely to get distracted by a campaigns table that has nothing to do with the bug you're fixing.

Infrawise's MCP tools are built around a specific answer to this: never send more schema than the task needs, and give the agent an explicit way to ask for exactly what it's missing.

The two bad defaults

Without something like this, an AI coding assistant reading your codebase has two options, and both are wrong in a different direction.

Option one: no schema at all. The model reads your source files, sees a DocumentClient.scan() call, and has no way to know that table has 50 million rows and a GSI it isn't using. It writes code that compiles and looks reasonable and is wrong the moment it touches production data — because "wrong" here isn't a syntax problem, it's a missing fact about your infrastructure that isn't in any file it can read.

Option two: dump everything, every time. Paste the full schema — every table, every column, every foreign key, every DynamoDB GSI — into the prompt so the model definitely has what it needs. This works, in the sense that the model now has the fact it's missing. It also means every single request pays for the full graph whether the task touches one table or fifteen. Context windows aren't free, and neither is the model's attention: the more irrelevant schema it has to read past, the more likely it latches onto the wrong table or a stale column name from a service you don't even own.

Infrawise's MCP server is designed around a third option: give the agent a cheap way to see what exists, then let it ask for detail only on the things it's actually going to touch.

How the lookup actually works

The server exposes 21 tools, but three of them define the whole pattern.

get_infra_overview is the entry point. It returns a compact snapshot — every table and collection by name and database type, queue and topic names, secret names, Lambda names, high-severity findings — no columns, no foreign keys, no indexes. It's meant to answer "what exists here" in a few hundred tokens, not "give me everything about it."

get_table_schema is where the actual detail lives, and it's scoped on purpose: it takes a list of 1 to 20 table or collection names and returns, per name, the columns with data types and nullability, primary keys, foreign keys (so an agent building a join knows the path without guessing), indexes, DynamoDB partition/sort keys, or a MongoDB estimated document count. Row data is never included — this is schema, not a data dump. Names are matched case-insensitively and by suffix, so asking for orders matches public.orders without the agent needing to know your schema prefix in advance. Ask for a table that doesn't exist and instead of a bare failure, you get up to five closest name matches back — useful when the agent guessed order instead of orders.

get_graph_summary is still there, and it still returns everything — every node, every edge, every finding, no filtering. It's the tool description that makes the intent explicit: it exists as the tool to reach for when you genuinely need the full picture across services, not the one an agent should reach for to answer "what does the orders table look like." The default path is get_infra_overview for orientation, get_table_schema for the two or three tables actually in scope, and get_graph_summary only when the task is broad enough to need it — reviewing an entire service, tracing relationships across five different tables and functions at once.

What this looks like on a real task

Take the checkout bug from the top. An agent working through it calls get_infra_overview once and learns there are 40 tables across Postgres and DynamoDB, plus a queue and a couple of Lambdas — cheap, one call, no column data yet. It's now looking at orders.ts, sees a query joining on payment_id, and calls get_table_schema with ["orders", "payments"]. Back comes exactly two schemas: column types, the foreign key from orders.payment_id to payments.id, and the indexes on both tables. That's the entire fetched context for the task — two tables, not forty.

If the bug turns out to touch inventory_reservations too, the agent just adds it to the next get_table_schema call. It never had to have asked for it upfront, and it never had to eat the cost of the other 37 tables it was never going to look at.

Compare that to the alternative most teams reach for without a tool like this: pasting the schema export once, keeping it in context, and hoping it doesn't drift as the schema changes. Infrawise's tables come from a fresh analysis (get_infra_overview even reports a freshness field with an age and a stale flag once the cached analysis passes 24 hours), so the agent knows when to ask for a re-run instead of working off of something that quietly went out of date three deploys ago.

Why this matters beyond the token count

The token savings are the visible part, but the more important effect is on accuracy. A model given forty tables' worth of columns has to do implicit filtering — figure out which of them are relevant, hold the rest as noise. Give it three tables that are actually in scope, and there's no filtering step: everything in context is something it's going to use. That's a smaller, sharper problem than "here's a schema, find what you need," and models are measurably better at smaller, sharper problems.

It also composes with what AGENTS.md calls out directly for large-database use cases — a text-to-SQL or query-writing agent should call get_infra_overview once per session for the table inventory, then get_table_schema only for the tables the current query touches, and treat get_graph_summary as the tool of last resort, not the default. That's the same pattern the checkout example walks through, just named as the recommended path for exactly the case where dumping everything hurts most — a database with hundreds of tables where "just paste the schema" was never realistic in the first place.

None of this requires the developer to think about it. You don't decide when to call get_table_schema versus get_graph_summary — the agent does, because the tool descriptions say when to reach for each one. The developer experience is just: ask Claude Code to fix the bug, and it already knows which two tables matter.

Key Takeaways

Two bad defaults exist for schema context: give an AI assistant nothing (it guesses and gets it wrong) or give it everything (it pays for and gets distracted by tables it will never touch).
get_infra_overview is a compact, column-free snapshot meant for orientation — names and types, not detail.
get_table_schema fetches full column, key, and index detail for up to 20 named tables at a time, matched case-insensitively by short name, with fuzzy suggestions on a miss.
get_graph_summary still returns the full graph — it's the explicit escape hatch for cross-service work, not the tool an agent should reach for to answer a question about two tables.
The pattern scales down naturally to large databases: fetch the inventory once per session, then pull schemas only for the tables the current task actually touches.

GitHub · npm

DEV Community: Siddharth Pandey

Your retry logic is correct and does nothing

The handler that is correct and does nothing

Why nobody catches this in review

Two ends of the same contract, two different findings

The rule that keeps it honest

What actually changed in the loop

Key takeaways

Your monorepo remembers infrastructure you deleted

A tool told someone to deploy a table from a stack they had deleted

How a deleted stack keeps its template

Why everything downstream believes it

The file the build rewrites every run

The exclusion that did not hold

What changed in the loop

Key takeaways

An empty result is not an all clear

false is a claim, and a failed call has no claim to make

The two exceptions are the interesting part

Four ways absence gets promoted to fact

Why this got urgent

The general shape

Key takeaways

Stale infrastructure context is worse than none

The bug that isn't a bug

Why the context has to be cached at all

What actually expires, and when

Refresh happens at the boundary you already have

Making age visible instead of silent

Conclusion

Key Takeaways

Your 12-Minute Frontend Build Is Now Your AI Agent's Bottleneck

The four taxes you are paying

Splitting without splitting the repo

The performance case, stated honestly

Where the AI speedup actually comes from

Migration path that does not stall

Key takeaways

Your Cognito Login Code Fails Because the App Client Never Allowed That Auth Flow

The app client is the config, and it is not in your repo

Reading the real client config

Turning it on

What this actually buys you

Key takeaways

Your Lambda Passes Tests Then Throws AccessDeniedException in Production

Why the assistant cannot see this on its own

What infrawise actually compares

Where you see it

Two things to know before you trust it

Try it

Key takeaways

How I Solved Claude Code Silently Missing the SQS Trigger on My Lambda

The problem: Claude Code didn't know the Lambda had an SQS trigger

The fix: infrawise's MCP tools in the loop, in order

What shipped instead

Why this is a repeatable pattern, not a one-off

Key takeaways

Your Lambda List Was Silently Truncated at 200 — And Your AI Assistant Never Knew

Hook

The 200-function wall

Why silent is worse than wrong

A pattern, not a one-off

The fix

Key Takeaways

The Right Way to Start Claude Code on an AWS Project

Section 1: One command, four steps

Section 2: Day two — you never type infrawise again

Section 3: Not a Claude Code shop? Same command, different flag

Section 4: What the assistant actually does with it

Conclusion

Key Takeaways

Why SNS Silently Drops Your Messages and How to Catch It Before You Ship

The contract nobody wrote down

Why your AI assistant writes the broken version

Pulling the contract into the coding session

Conclusion

Key Takeaways

Stop Sending Your AI Assistant 40 Tables When It Only Needs 3

The two bad defaults

How the lookup actually works

`false` is a claim, and a failed call has no claim to make

Section 2: Day two — you never type `infrawise` again