Transaction message check back

[lixinwen]

The issue tracker is ONLY used for bug report and feature request. Keep in mind, please check whether there is an existing same report before your raise a new one.

Alternately (especially if your communication is not a bug report), you can send mail to our mailing lists. We welcome any friendly suggestions, bug fixes, collaboration and other improvements.

Please ensure that your bug report is clear and that it is complete. Otherwise, we may be unable to understand it or to reproduce it, either of which would prevent us from fixing the bug. We strongly recommend the report(bug report or feature request) could include some hints as the following:

BUG REPORT

1. Please describe the issue you observed:
   In TransactionalMessageBridge.getMessage method,
   when store return status is OFFSET_OVERFLOW_ONE, PullStatus.OFFSET_ILLEGAL will be set to PullResult, so, in TransactionServiceImpl.fillOpRemoveMap method, the code as follows will be execute:
   transactionalMessageBridge.updateConsumeOffset(opQueue, pullResult.getNextBeginOffset());
   this will result opQueueOffset error.

• What did you do (The steps to reproduce)?

• What did you expect to see?
  I think should set the PullStatus.NO_NEW_MSG to PullResult in this TransactionalMessageBridge.getMessage method, because of it's no offset overflow,
  just like the process method of PullMessageProcessor.

• What did you see instead?

2. Please tell us about your environment:
   Local mac pro

3. Other information (e.g. detailed explanation, logs, related issues, suggestions how to fix, etc):

FEATURE REQUEST

1. Please describe the feature you are requesting.

2. Provide any additional detail on your proposed use case for this feature.

3. Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?

4. If there are some sub-tasks using -[] for each subtask and create a corresponding issue to map to the sub task:

• sub-task1-issue-number: sub-task1 description here,
• sub-task2-issue-number: sub-task2 description here,
• ...

[ymwneu]

You are right, set PullStatus.NO_NEW_MSG in this situation is better.
But I think set PullStatus.OFFSET_ILLEGAL is also ok. If store#getMessage return OFFSET_OVERFLOW_ONE, the value of pullResult.getNextBeginOffset() is equal to the query offset. So transactionalMessageBridge#updateConsumeOffset just reset the same value, this will not cause offset error.

[lixinwen]

You are right, set PullStatus.NO_NEW_MSG in this situation is better.
But I think set PullStatus.OFFSET_ILLEGAL is also ok. If store#getMessage return OFFSET_OVERFLOW_ONE, the value of pullResult.getNextBeginOffset() is equal to the query offset. So transactionalMessageBridge#updateConsumeOffset just reset the same value, this will not cause offset error.

Yeah, you are right, no serious consequences found at present.