Bugzilla

Based on the description in comment 0, it seems to be an architectural bug in how sessionId is generated, for which I think it would be a good idea to file a bug in the SR component that blocks this bug. We need a new owner for SR, but I still don't know who may be, I'd suggest to directly ping mdb on Slack to move this on.
I can't easily answer the question, because I'm not even sure why sessionId was defined as a number, and not a uuid or a guid, that would have a much smaller chance of being a dupe in case of code mistakes. Probably the fix here is about changing the sessionId on restore and not trust the old one, or immediately increase _nextClosedId, unless the architecture chan be easily changed to use a likely-unique identifier.

PS: while searching the source I found a typo here https://searchfox.org/mozilla-central/rev/2bc4e5cdf669cc9de3ed98e38be3e50a27b25332/browser/components/extensions/test/browser/browser_ext_sessions_incognito.js#94 not sure if/how this has consequences.

Based on the description in comment 0, it seems to be an architectural bug in how sessionId is generated, for which I think it would be a good idea to file a bug in the SR component that blocks this bug. We need a new owner for SR, but I still don't know who may be, I'd suggest to directly ping mdb on Slack to move this on.
I can't easily answer the question, because I'm not even sure why sessionId was defined as a number, and not a uuid or a guid, that would have a much smaller chance of being a dupe in case of code mistakes. Probably the fix here is about changing the sessionId on restore and not trust the old one, or immediately increase _nextClosedId, unless the architecture can be easily changed to use a likely-unique identifier.

PS: while searching the source I found a typo here https://searchfox.org/mozilla-central/rev/2bc4e5cdf669cc9de3ed98e38be3e50a27b25332/browser/components/extensions/test/browser/browser_ext_sessions_incognito.js#94 not sure if/how this has consequences.

Based on the description in comment 0, it seems to be an architectural bug in how sessionId is generated, for which I think it would be a good idea to file a bug in the SR component that blocks this bug. We need a new owner for SR, but I still don't know who may be, I'd suggest to directly ping mdb on Slack to move this on.
I can't easily answer the question, because I'm not even sure why sessionId was defined as a number, and not a uuid or a guid, that would have a much smaller chance of being a dupe in case of code mistakes. Probably the fix here is about changing the sessionId on restore and not trust the old one, or immediately increase _nextClosedId, unless the architecture can be easily changed to use a likely-unique identifier.

PS: while searching the source I found a typo (sesionId) here https://searchfox.org/mozilla-central/rev/2bc4e5cdf669cc9de3ed98e38be3e50a27b25332/browser/components/extensions/test/browser/browser_ext_sessions_incognito.js#94 not sure if/how this has consequences.