Skip to content

tronbox-upgrades: exercise the full-fidelity storage-layout path once TronBox emits storageLayout #12

Description

@nahimterrazas

Follow-up from the PR #11 review (general comment): the reviewer asked for an issue tracking that detectFidelity must inspect actual storageLayout presence when TronBox starts emitting it, instead of assuming declaration-order-only comparison — otherwise the degraded-mode disclosure becomes a false statement over what would actually be a full-fidelity comparison.

Current state (post PR #11): detectFidelity (packages/tronbox-upgrades/src/validation-input/layout-fidelity.ts) already performs a live per-contract scan of the build record's solc output: it checks each contract's storageLayout presence and position completeness, and returns slot-level fidelity when every contract has a usable layout, declaration-order-only (with the missing census) otherwise. The scan runs unconditionally on every produced input precisely so that the day the host starts emitting layouts, this call is what notices.

What remains — and what this issue tracks:

  1. No supported TronBox emits storageLayout today. No supported TronBox version requests it in outputSelection, so the slot-level branch is currently unreachable with real TronBox artifacts; it is exercised only by synthetic fixtures. The upstream complement is small: TronBox needs to request storageLayout in its solc outputSelection (and the TRON dev-chainId handling upstream — see validateBaseSlotUnchanged never fires when layouts are read through unfoldStorageLayout openzeppelin-upgrades#1296, still unshipped upstream as of 2026-08-07).
  2. End-to-end verification once emission lands: with a TronBox build that emits layouts, verify (a) detectFidelity flips to slot-level on real artifacts, (b) the upgrade-safety comparison actually consumes the emitted layouts (slot/offset/type-level diffs, not declaration order), and (c) the degraded note is no longer attached to those runs — the disclosure must track the comparison actually performed.
  3. Mixed-census behavior: decide and pin behavior when only part of the census carries layouts (today: any missing contract degrades the whole input to declaration-order-only, with the census listed).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions