kutsibalci commented on PR #23098:
URL: https://github.com/apache/kafka/pull/23098#issuecomment-5257379177
Ping — the build has never run on this PR. Five days in, the only workflows
that have reported are `Labeler` and `Add triage label`; no CI job has started,
which I take to be the approval gate for a first-time contributor rather than
anything about the patch.
@chia7712 — could you, or anyone with the button, release the workflow run?
Happy to rebase onto current `trunk` first if that is easier.
A recap, since most of the diff is the new test. On `trunk` today:
```java
return issueTimestamp == that.issueTimestamp &&
maxTimestamp == that.maxTimestamp &&
Objects.equals(owner, that.owner) &&
Objects.equals(tokenRequester, that.tokenRequester) &&
Objects.equals(renewers, that.renewers) &&
Objects.equals(tokenId, that.tokenId); // equals: six fields
...
return Objects.hash(owner, tokenRequester, renewers, issueTimestamp,
maxTimestamp, expiryTimestamp, tokenId);
// hashCode: those six
plus expiryTimestamp
```
`expiryTimestamp` is mutable through the public `setExpiryTimestamp`, which
`DelegationTokenControlManager` calls on renewal. So two instances that
`equals` reports as equal can hash differently, and the same instance changes
its hash code in place — the `Object.hashCode` contract in both directions. A
`TokenInformation` used as a `HashMap` key or held in a `HashSet` before a
renewal is not found after it.
The fix drops `expiryTimestamp` from `hashCode` so the two agree on the same
six fields, and `TokenInformationTest` covers both directions.
*AI disclosure: AI-assisted (Claude Code). I verified the field lists and
the `setExpiryTimestamp` call sites against `trunk` before posting and take
responsibility for the change.*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
