It is only used in case of transaction errors, which are usually not going to work on second try if they failed once.
2023-11-01 30538, 2023
kellnerd
Unless I am missing something, it should always be better to simply add these items to the failure queue instead of immediately trying to repeat the import.
2023-11-01 30527, 2023
kellnerd
And by dropping this loop, I can remove a lot of boiler plate code here and inline the whole consumeRecord function/module.
2023-11-01 30532, 2023
kellnerd
What do you think?
2023-11-01 30552, 2023
monkey
Hi kellnerd ! Yes I had looked at the comment in question suggestion to drop it.
2023-11-01 30552, 2023
monkey
I'm not sure what the possible failure modes are going to be, but I agree it doesn't make a lot of sense to retry on any failure, expecting another failure. Indeed I think this is for the failureQueue to deal with. I am all for simplifying code and removing asynchronous loops where possible which usually make the code more brittle
2023-11-01 30510, 2023
monkey
Assuming `TRANSACTION_ERROR` errors won't be less of an error if we retry with the same record
2023-11-01 30518, 2023
kellnerd
Yeah, currently it is hard to see which error type and message is caused by what unless you open consumer.ts and consumeRecord.ts side by side.
2023-11-01 30518, 2023
kellnerd
I've been refactoring these messages to have less redundancy and it was a bit hard to follow what happens...
