feat: pact contract for get job by id and post job by duvanmoionq · Pull Request #106 · ionq/ionq-core-python

duvanmoionq · 2026-09-09T16:47:44Z

install pact dependency
Adding pact contract for http POST /job
Adding pact contract for http GEt /job/{id}

antalszava · 2026-09-10T20:56:23Z

Thank you @duvanmoionq! before a full review, a question: should the new tests be added to the CI too? or does pact work in a different way?

duvanmoionq · 2026-09-14T19:29:14Z

Thank you @duvanmoionq! before a full review, a question: should the new tests be added to the CI too? or does pact work in a different way?

Yes! we would do that later for now we are only adding test contracts examples that we can follow to add more contracts. we will add later the CI logic whenever we configure the Broker we need.

antalszava

Thank you so much @duvanmoionq! 👏 Very interesting direction.

I've left a couple of comments, my main feedback is: could we somehow dynamically depend on the API spec that we have in the repo in the pact?

Also, could you further describe what we gain from using pact instead of "simply" writing pytest tests with expected responses?

antalszava · 2026-09-14T21:13:49Z

@@ -0,0 +1,165 @@
+"""Pact HTTP contract: ionq-core-python (consumer) -> cloud-job-manager (provider).


Is it a convention to have a consumers folder inside the pact folder?

First it seems a bit unnecessary to have two levels of folder nesting atm.

Yes that's the convention we decided to follow in all the repos.

antalszava · 2026-09-14T21:15:30Z

+"""Pact HTTP contract: ionq-core-python (consumer) -> cloud-job-manager (provider).
+
+Pins the two jobs-API interactions the SDK depends on, in ONE pact
+(ionq-core-python-cloud-job-manager.json):


The mention of ionq-core-python-cloud-job-manager.json seems a bit confusing here since it's not a file in the repo - where does it live?

I removed that comment but I will keep cloud-job-manager-http because that's the name of the provider.

antalszava · 2026-09-14T21:17:40Z

+Pins the two jobs-API interactions the SDK depends on, in ONE pact
+(ionq-core-python-cloud-job-manager.json):
+
+  1. POST /v0.4/jobs        create a circuit job   -> 201 {id, status, session_id}


This endpoint can have different inputs: single-circuit,multi-circuit, quantum function and qaoa function. Should that matter here/does that matter for the contract?

Yes that's very true. and that's the idea! so we can add contracts to cover all cases. but for now the idea of this PR is just to add an example, structure to follow.

antalszava · 2026-09-14T21:21:56Z

+  1. POST /v0.4/jobs        create a circuit job   -> 201 {id, status, session_id}
+  2. GET  /v0.4/jobs/{id}   fetch a completed job  -> 200 (every SingleCircuitJob


Imho these should be coming dynamically from this repo's API spec version. Accordingly, I think it would be good to remove/keep the endpoint and payload descriptions minimal here because they need to be changed here each time their spec changes.

antalszava · 2026-09-14T21:35:34Z

+    PACT_DIR.mkdir(exist_ok=True)
+    pact.write_file(PACT_DIR, overwrite=True)


What do these instructions do?

They create the consumer contract file(pacts/ionq-core-python-cloud-job-manager.json) that is published to the pact broker.

thank you! what is in the consumer contract right now? is it empty?

duvanmoionq · 2026-09-18T21:00:59Z

Thank you so much @duvanmoionq! 👏 Very interesting direction.

I've left a couple of comments, my main feedback is: could we somehow dynamically depend on the API spec that we have in the repo in the pact?

Also, could you further describe what we gain from using pact instead of "simply" writing pytest tests with expected responses?

About dynamically depending on the API spec, I am no sure I follow what you mean, what do you have in mind?
For the gain using pact, this is not a simple test. it looks like a test but the main work is actually on the broker side, as an example this Repo is the consumer and the source of truth, so we create the contract of what the sdk expects for some cases like creating a job or getting some results, but the producer is the one that actually verifies and make sure the contract is complaying the expectation so every time someone creates a new change on the API, contracts will be verified on the broker and make sure they don't break this consumer contract. for more details there is a cool video here that allow you to understand better https://docs.pact.io/.

antalszava · 2026-09-21T13:08:48Z

The PR is now looking good, just posting more on our discussion (once settled, this is looking great 👍).

About dynamically depending on the API spec, I am no sure I follow what you mean, what do you have in mind?

Right now, everything is hardcoded: there's a CREATE_PAYLOAD, CREATE_RESPONSE_BODY and GET_RESPONSE_BODY objects. Each time there's a change in the API that influences these hardcoded objects, they have to be updated too. On the other hand, the API spec data served at https://api.ionq.co/v0.4/api-docs (or more conretely in this repo, the content of https://github.com/ionq/ionq-core-python/blob/main/openapi.json) is meant to be the source of truth to what each API endpoint looks like - meaning that any change to the API is reflected there too (theoretically). What I mean is, can't we use for example the "examples" section of the API spec to pull in examples from there instead of creating a job payload programmatically in the test? Same for the responses.

For the gain using pact, this is not a simple test. it looks like a test but the main work is actually on the broker side, as an example this Repo is the consumer and the source of truth, so we create the contract of what the sdk expects for some cases like creating a job or getting some results, but the producer is the one that actually verifies and make sure the contract is complaying the expectation so every time someone creates a new change on the API, contracts will be verified on the broker and make sure they don't break this consumer contract. for more details there is a cool video here that allow you to understand better https://docs.pact.io/.

Do I understand it correctly, that on the broker side the expectations are coded up and then any consumer (ionq-core being one) can be tested using those contracts? What is the expectation coming from ionq-core to the provider?

duvanmoionq · 2026-09-21T13:26:04Z

CREATE_RESPONSE_BODY

I see what you mean, but that will go against what pact said we should do, pact contracts needs to use payload for what the SDK really uses, open spec have many things that the SDK don't event use. so for example GET_RESPONSE_BODY uses matchers for fields we really use, and if any one change it on the consumer or the provider the contract will fail. that's why we do it that way. what we can do is that we can be more strict with the matchers we use on these payloads. for the case of create a job there are so many contracts we could implement.

and about his question
Do I understand it correctly, that on the broker side the expectations are coded up and then any consumer (ionq-core being one) can be tested using those contracts? What is the expectation coming from ionq-core to the provider?
It is the other side, consumers are the ones who set the expectation and the provider is the one that verify we meet the expectations for each consumer.

feat: pact contract for get job by id and post job

eda1b3c

duvanmoionq requested a review from a team as a code owner September 9, 2026 16:47

duvanmoionq added 2 commits September 9, 2026 12:01

chore: fix contract test error

61b0d32

fix: lint issue

c2347e3

antalszava self-requested a review September 10, 2026 12:04

antalszava reviewed Sep 14, 2026

View reviewed changes

duvanmoionq added 2 commits September 15, 2026 17:38

chore: new ci publish logic for http pact contracts

9f4c423

chore: improve the comments in the new consumer contract

a1b7c59

Merge branch 'main' into pact/contract

0ecf47f

antalszava reviewed Sep 21, 2026

View reviewed changes

Comment thread tests/pact/consumers/test_jobs_get.py

duvanmoionq added 2 commits September 21, 2026 08:40

chore: split consumer by endpoint

b177f9f

chore: remove comments

a123fac

		@@ -0,0 +1,165 @@
		"""Pact HTTP contract: ionq-core-python (consumer) -> cloud-job-manager (provider).

		1. POST /v0.4/jobs create a circuit job -> 201 {id, status, session_id}
		2. GET /v0.4/jobs/{id} fetch a completed job -> 200 (every SingleCircuitJob

		PACT_DIR.mkdir(exist_ok=True)
		pact.write_file(PACT_DIR, overwrite=True)

Conversation

duvanmoionq commented Sep 9, 2026 • edited by atlassian Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

antalszava commented Sep 10, 2026

Uh oh!

duvanmoionq commented Sep 14, 2026

Uh oh!

antalszava left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duvanmoionq Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

duvanmoionq commented Sep 18, 2026

Uh oh!

Uh oh!

antalszava commented Sep 21, 2026

Uh oh!

duvanmoionq commented Sep 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

duvanmoionq commented Sep 9, 2026 •

edited by atlassian Bot

Loading

duvanmoionq Sep 17, 2026 •

edited

Loading