Skip to content

[Bug] Extra persistance of propertiesString #9469

Open
@WJ66880

Description

@WJ66880

Before Creating the Bug Report

  • I found a bug, not just asking a question, which should be created in GitHub Discussions.

  • I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

  • I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

It has noting to do with OS

RocketMQ version

I found this bug in 4.3.2 version, but the latest version also has this bug.

JDK Version

It has noting to do with JDK

Describe the Bug

Based on two principles:

  1. For a message, its properties map and propertiesString should keep equal with each other, bug only propertiesString need to persist.
  2. No matter which type of a message, such as transaction message、delay message、reconsumed message, when delivered into the final business topic, it shoud be pure, without and special marks, suan as TRANS_MSG、DELAY. Because thease marks are only RocketMQ inner, I think. A message with these marks is the
    source of many bugs, for instance, the half message with delay level bug.

This bug exists in two situations:

  1. Transation message, before sendFinalMessage method, threee properties should be cleared before setPropertiesString, othewise, the final message will be delivered with the token of TRANS_MSG. and we have to save three more properties into commitlog.
  2. Delay message, on messsage time up, have the save question.

Steps to Reproduce

Send a transaction message, a consumer receive it with TRANS_MSG property.

Image

When reconsume a message, a consumer receive it with DELAY property.

Image

What Did You Expect to See?

A final business message should be pure, without any rocketmq inner properties. It's really a source of bugs. Besides, it doesn't match the designment.

What Did You See Instead?

  1. For a message, its propertiesString and properties map should keep equal with each other.
  2. A final business message should be pure, without any rocketmq inner properties. It's really a source of bugs. Besides, it doesn't match the designment.

Additional Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions