Skip to content

e2e: test-oz-reputation.js targets the removed feedback-authorization ABI #536

Description

@omarespejel

Found while correcting the ABI drift in skills/starknet-identity/SKILL.md (#535). CodeRabbit flagged it there; filing separately because #535 is docs-only.

contracts/erc8004-cairo/e2e-tests/test-oz-reputation.js calls give_feedback against an ABI that no longer exists:

const feedbackTx = await reputationRegistry.give_feedback(
  cairo.uint256(agentId),
  92,
  cairo.uint256(100),          // tag1 is a ByteArray, not a u256
  cairo.uint256(200),          // tag2 likewise
  'ipfs://oz-feedback.json', // lands on endpoint
  cairo.uint256(0xABCDEF),     // lands on feedback_uri
  feedbackAuth,                // no such parameter
  signature                    // no such parameter
);

The deployed entrypoint takes nine parameters: agent_id, value, value_decimals, tag1, tag2, endpoint, feedback_uri, feedback_hash. There is no authorization proof and no signature. The registry gates feedback with assert(!identity_registry.is_authorized_or_owner(caller, agent_id), 'Self-feedback not allowed'), so the whole createFeedbackAuthHash / signMessage flow in this file is vestigial. It also omits value_decimals entirely, which shifts every remaining argument.

Suggested fix: delete the file. It looks orphaned rather than merely stale:

  • nothing references test-oz-reputation anywhere in the repo
  • it is in no package.json script (test, test:reputation, test:all all point at test-runner.js / tests/*.test.js)
  • CI does not run the e2e suite at all
  • contracts/erc8004-cairo/e2e-tests/tests/reputation.test.js already covers reputation against the current ABI, with correct serialization via byteArrayFromString and cairo.uint256

So it is dead code that reads as a working reference and would mislead anyone who copies from it. If it is kept for historical reasons it should be renamed to mark it legacy, but the maintained path is tests/reputation.test.js.

Not doing this in #535 to keep that PR docs-only, and because validating any e2e rewrite needs a devnet run.

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