Skip to content
This repository was archived by the owner on Jul 10, 2026. It is now read-only.

test: ci cache probe (identical to #132) - #133

Closed
xorsal wants to merge 5 commits into
devfrom
test/ci-cache-probe
Closed

test: ci cache probe (identical to #132)#133
xorsal wants to merge 5 commits into
devfrom
test/ci-cache-probe

Conversation

@xorsal

@xorsal xorsal commented May 26, 2026

Copy link
Copy Markdown
Contributor

Identical tree to #132 on a fresh branch — probing whether Actions/AdvSec suppression is keyed on the head sha or on the branch.

@qodo-code-review

qodo-code-review Bot commented May 26, 2026

Copy link
Copy Markdown

Review Summary by Qodo

(Agentic_describe updated until commit 1070279)

Flip counter test assertion for CI cache validation

🧪 Tests

Grey Divider

Walkthroughs

Description
• Modified counter test assertion to fail intentionally
• Changed expected counter value from 1n to 999n
• Probing CI cache behavior on fresh branch
Diagram
flowchart LR
  A["Counter Test"] -- "Change assertion" --> B["Expected: 1n → 999n"]
  B -- "Trigger CI" --> C["Probe cache behavior"]

Loading

Grey Divider

File Changes

1. src/ts/counter.test.ts 🧪 Tests +1/-1

Flip counter assertion for CI validation

• Modified test assertion in counter contract test
• Changed expected counter value from 1n to 999n
• Test now intentionally fails to probe CI cache behavior
• No changes to test logic or setup

src/ts/counter.test.ts


Grey Divider

Qodo Logo

@qodo-code-review

qodo-code-review Bot commented May 26, 2026

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 1070279

Comment thread src/ts/counter.test.ts
})
).result,
).toBe(1n);
).toBe(999n);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Wrong increment expectation 🐞 Bug ≡ Correctness

src/ts/counter.test.ts now asserts the counter becomes 999n after a single increment(), but
the contract increments by exactly 1 from the default 0. This will fail CI and misrepresents the
Counter contract behavior.
Agent Prompt
## Issue description
The TypeScript e2e test expects `999n` after a single `increment()`, but the Counter contract increments the stored counter by `+1`, so the correct expected value is `1n`.

## Issue Context
- Contract logic increments `current_value + 1`.
- Noir tests already assert the post-increment value is `1`.

## Fix Focus Areas
- src/ts/counter.test.ts[55-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/ts/counter.test.ts">

<violation number="1" location="src/ts/counter.test.ts:55">
P1: The test expectation was changed to an incorrect counter value (`999n`), which breaks the correctness of this integration test.</violation>
</file>

Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic

Comment thread src/ts/counter.test.ts
})
).result,
).toBe(1n);
).toBe(999n);

@cubic-dev-ai cubic-dev-ai Bot May 26, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: The test expectation was changed to an incorrect counter value (999n), which breaks the correctness of this integration test.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/ts/counter.test.ts, line 55:

<comment>The test expectation was changed to an incorrect counter value (`999n`), which breaks the correctness of this integration test.</comment>

<file context>
@@ -52,6 +52,6 @@ describe("Counter Contract", () => {
         })
       ).result,
-    ).toBe(1n);
+    ).toBe(999n);
   });
 });
</file context>
Suggested change
).toBe(999n);
).toBe(1n);
Fix with Cubic

@xorsal xorsal closed this May 26, 2026
@xorsal xorsal reopened this May 26, 2026
@qodo-code-review

qodo-code-review Bot commented May 26, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

Grey Divider


Action required

1. Wrong increment expectation 🐞 Bug ≡ Correctness
Description
src/ts/counter.test.ts now asserts the counter becomes 999n after a single increment(), but
the contract increments by exactly 1 from the default 0. This will fail CI and misrepresents the
Counter contract behavior.
Code

src/ts/counter.test.ts[55]

Evidence
The contract’s increment_internal reads the current counter and writes current_value + 1, and
the Noir test suite validates that one increment results in counter value 1. Therefore, expecting
999n in the TS e2e test is inconsistent and will fail when the contract behaves as implemented.

src/ts/counter.test.ts[36-56]
src/nr/counter_contract/src/main.nr[50-56]
src/nr/counter_contract/src/test/increment.nr[7-11]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The TypeScript e2e test expects `999n` after a single `increment()`, but the Counter contract increments the stored counter by `+1`, so the correct expected value is `1n`.

## Issue Context
- Contract logic increments `current_value + 1`.
- Noir tests already assert the post-increment value is `1`.

## Fix Focus Areas
- src/ts/counter.test.ts[55-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

  • Author self-review: I have reviewed the code review findings, and addressed the relevant ones.

Previous review results

Review updated until commit 1070279

Results up to commit 1070279


🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)


Action required
1. Wrong increment expectation 🐞 Bug ≡ Correctness
Description
src/ts/counter.test.ts now asserts the counter becomes 999n after a single increment(), but
the contract increments by exactly 1 from the default 0. This will fail CI and misrepresents the
Counter contract behavior.
Code

src/ts/counter.test.ts[55]

Evidence
The contract’s increment_internal reads the current counter and writes current_value + 1, and
the Noir test suite validates that one increment results in counter value 1. Therefore, expecting
999n in the TS e2e test is inconsistent and will fail when the contract behaves as implemented.

src/ts/counter.test.ts[36-56]
src/nr/counter_contract/src/main.nr[50-56]
src/nr/counter_contract/src/test/increment.nr[7-11]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The TypeScript e2e test expects `999n` after a single `increment()`, but the Counter contract increments the stored counter by `+1`, so the correct expected value is `1n`.

## Issue Context
- Contract logic increments `current_value + 1`.
- Noir tests already assert the post-increment value is `1`.

## Fix Focus Areas
- src/ts/counter.test.ts[55-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

@qodo-code-review

Copy link
Copy Markdown

CI Feedback 🧐

A test triggered by this PR failed. Here is an AI-generated analysis of the failure:

Action: benchmark / Benchmark

Failed stage: Set up job [❌]

Failed test name: ""

Failure summary:

The workflow failed during the "Prepare all required actions" step because GitHub Actions could not
download the referenced action
dawidd6/action-download-artifact@0bd50d53a6d7fb5cb921e607957e9cc12b4ce392.
The runner reported that
no action archive was found at
https://codeload.github.com/dawidd6/action-download-artifact/tar.gz/0bd50d53a6d7fb5cb921e607957e9cc12b4ce392
and the download failed after 1 attempt (log lines 33-34).

Relevant error logs:
1:  ##[group]Runner Image Provisioner
2:  Hosted Compute Agent
...

18:  ##[endgroup]
19:  ##[group]GITHUB_TOKEN Permissions
20:  Actions: read
21:  Contents: read
22:  Issues: write
23:  Metadata: read
24:  PullRequests: write
25:  ##[endgroup]
26:  Secret source: Actions
27:  Prepare workflow directory
28:  Prepare all required actions
29:  Getting action download info
30:  Download action repository 'actions/checkout@v4' (SHA:34e114876b0b11c390a56381ad16ebd13914f8d5)
31:  Download action repository 'defi-wonderland/aztec-ci-actions@v0' (SHA:93c99c377be187f542415c0f944d21d68614c74e)
32:  Download action repository 'dawidd6/action-download-artifact@0bd50d53a6d7fb5cb921e607957e9cc12b4ce392' (SHA:0bd50d53a6d7fb5cb921e607957e9cc12b4ce392)
33:  ##[error]An action could not be found at the URI 'https://codeload.github.com/dawidd6/action-download-artifact/tar.gz/0bd50d53a6d7fb5cb921e607957e9cc12b4ce392' (BC01:2A2CA6:A0827:D2272:6A159686)
34:  ##[error]Failed to download archive 'https://codeload.github.com/dawidd6/action-download-artifact/tar.gz/0bd50d53a6d7fb5cb921e607957e9cc12b4ce392' after 1 attempts.

@xorsal xorsal closed this May 28, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant