镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

[ISSUE #11037] Encode delay message propertiesString after clearing internal properties - #11505

Open
lihanyu1715446406-afk wants to merge 1 commit into
apache:developfrom
lihanyu1715446406-afk:fix/delay-properties-string-after-clear
Open

lihanyu1715446406-afk wants to merge 1 commit into
apache:developfrom
lihanyu1715446406-afk:fix/delay-properties-string-after-clear

Conversation

@lihanyu1715446406-afk

Copy link
Copy Markdown

What is the purpose of the change

ScheduleMessageService#messageTimeUp encodes propertiesString from msgExt.getProperties() before removing the internal scheduling properties. MessageAccessor.clearProperty only removes entries from the in-memory property map, so the encoded wire data — which is what gets persisted and decoded by consumers — still carries DELAY_TIME_LEVEL, TIMER_DELIVER_MS and TIMER_DELAY_SEC.

Move the encoding after the clearProperty calls and encode msgInner.getProperties(), matching the ordering already used by TimerMessageStore#convertMessage (the timer-wheel path fixed in #10972).

Brief changelog

  • Encode propertiesString after the internal properties are cleared.
  • Add ScheduleMessageServiceTest#testMessageTimeUpPropertiesStringMatchesProperties, which asserts that the delivered message's propertiesString contains none of the internal properties and equals a re-encoding of the final property map.

Verifications

  • Without the production change, the new test fails with AssertionError on assertFalse(delivered.getPropertiesString().contains(PROPERTY_DELAY_TIME_LEVEL)).
  • With the change: Tests run: 5, Failures: 0, Errors: 0, Skipped: 0.

Fixes #11037.

Note: an earlier attempt, #11038, was closed unmerged. This PR is an independent implementation of the fix with a regression test, as the issue is still open.

…ring internal properties

ScheduleMessageService#messageTimeUp encoded msgInner.propertiesString from
msgExt.getProperties() before PROPERTY_DELAY_TIME_LEVEL,
PROPERTY_TIMER_DELIVER_MS and PROPERTY_TIMER_DELAY_SEC were cleared.
MessageAccessor.clearProperty only removes entries from the property map,
so the persisted wire data kept the internal properties while the in-memory
map did not.

Encode after the properties are finalized, matching the ordering already
used by TimerMessageStore#convertMessage. Add a regression test that
asserts the delivered propertiesString contains none of the internal
properties and equals a re-encoding of the final property map.
@lihanyu1715446406-afk

Copy link
Copy Markdown
Author

Friendly ping — could a committer approve the CI run for this PR? The regression test fails without the production change and passes with it. Happy to adjust anything if needed.

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.

[Bug] Delay messages are delivered with internal properties leaked into propertiesString (ScheduleMessageService#messageTimeUp)

1 participant