Skip to content

fix(deviceauth): Allow new authset for accepted devices at max limit - #2055

Draft
bahaa-ghazal wants to merge 1 commit into
mendersoftware:mainfrom
bahaa-ghazal:MEN-9955
Draft

fix(deviceauth): Allow new authset for accepted devices at max limit#2055
bahaa-ghazal wants to merge 1 commit into
mendersoftware:mainfrom
bahaa-ghazal:MEN-9955

Conversation

@bahaa-ghazal

Copy link
Copy Markdown
Contributor

Ticket: MEN-9955

Will add ng test in enterprise, since there is no limits is OS

@bahaa-ghazal
bahaa-ghazal requested a review from a team July 13, 2026 13:05
@codecov

codecov Bot commented Jul 13, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@merlin-northern merlin-northern left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I would really love an expicit test scenarion for this in the tests-ng, doable?

dev.AuthSets = []model.AuthSet{*aset}

reqId := requestid.FromContext(ctx)
if !deviceAlreadyAccepted {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

cold you double check, I understand the change, in here we used to start the provision no matter what, and if the device had been accepted and we set the auth set status to accepted this seems not necessary to start the provision workflow, could you doble check that we for sure do not rely on that? I do not think so, but this function is a huge trap.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The only case I can think of that this might break is that if we try to accept an authset for a existing device but with different tier then the one accepted. Do we allow that change of tiers for accepted device? or the device must be rejected first then re-accepted with the new tier?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

tiers do not exist in os, so on this you have to fall in ent. but the tier change works by accepting a new authset, and yes, the device stays accepted.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

you know what, it wont hurt do add provision_device call in OS. we need that in enterprise because it used the provision_device_v2 which gets attributes as param to the workflow. we can just keep the first part of skipping counting limits if device is accepted

@bahaa-ghazal bahaa-ghazal Jul 14, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I hate the sync ... the enterprise would need a different fix because of tiers

@bahaa-ghazal
bahaa-ghazal requested a review from alfrunes July 14, 2026 09:14
Ticket: MEN-9955
Signed-off-by: Bahaa Aldeen Ghazal <bahaa.ghazal@northern.tech>
@bahaa-ghazal
bahaa-ghazal marked this pull request as draft July 15, 2026 08:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants