Meshie
All documentation

Unknown edges

Sometimes Meshie can see that something reaches a field without being able to say what. That case has a name, a colour, and an exit code, because the honest answer to it is never silence.

What an unknown edge is

Most references resolve. A formula names a field, a flow names an object, a dbt model names a column: the extractor reads the reference and records an edge with a type, a confidence and the file it came from.

Some do not. Apex that builds a field name from a string at runtime, a query assembled from configuration, an integration mapping that points at a value no static reader can follow. The reference is real and visible, but what it points at cannot be determined without running the code.

Meshie records those as edges of type UNKNOWN rather than dropping them. Dropping them would be the dangerous choice: the graph would look complete and be wrong.

Why it propagates to the node

Any node that an unknown edge reaches carries reachable_from_unknown: true. It is a property of the node, not of one reference, because that is how it gets used: before you delete a field, the question is not “is this particular edge solid” but “is there anything at all I cannot see”.

The flag is set once, when the snapshot is built, and read everywhere after that. No surface recomputes it and none can bypass it.

What it changes

  • In the app: the impact verdict says so outright. When nothing else references the field, the verdict is not “unused” but “can’t confirm this field is unused”, shown in red rather than as a neutral result. When there are other references, the list carries a line saying it may be incomplete.
  • In the unused list: not yet, and this is worth knowing. That list counts four kinds of resolved reference, so a field whose only inbound reference is unresolvable still appears on it. The risk note on every finding says so, and Impact is where the flag itself is read. Check a candidate there before acting on it.
  • In the CLI: meshie impact exits 5. Not 0, because you should not merge on the strength of the answer; not 1, because there is an answer and it is still on stdout.
$ meshie impact salesforce:CustomField:Account.Legacy_Code__c
impact: salesforce:CustomField:Account.Legacy_Code__c
  WARNING: reachable via an UNKNOWN edge, cannot be fully verified
  2 direct reference(s):
    ...
$ echo $?
5
Exit 5 with a result, rather than a silent success.

A limit worth knowing

The flag is computed inside each system’s own scan, before the systems are merged into one graph. Within a system it is exact: anything downstream of an unresolvable reference carries it. Across systems it is not yet propagated, so an unknown edge in Salesforce does not currently mark a warehouse column that a sync feeds from the affected field.

In practice that means the flag is a floor in the same way the impact list is: where you see it, believe it; not seeing it on a node in another system is not proof of anything. We would rather write that down than let you infer a guarantee we do not make yet.

What to do about one

  • Open the evidence. The unknown edge still carries the file it was found in, which is usually enough for the person who owns that code to say in a minute whether the reference is live.
  • Connect more systems. Some unknown edges are only unknown because the system on the other end is not connected yet, and the reference resolves once it is.
  • Leave the field. “We could not prove this is safe” is a perfectly good reason not to delete something, and it is the reason this product exists.

The same discipline runs through the rest of the graph: see Tiers and confidence for how the edges that do resolve are weighted.