Exam Professional Data Engineer topic 1 question 109 discussion

Answer C E By not acknowleding the pulled message, this result in it be putted back in Cloud Pub/Sub, meaning the messages accumulate instead of being consumed and removed from Pub/Sub. The same thing can happen ig the subscriber maintains the lease on the message it receives in case of an error. This reduces the overall rate of processing because messages get stuck on the first subscriber. Also, errors in Cloud Function do not show up in Stackdriver Log Viewer if they are not correctly handled.

The issue is that the acknowledgment is not sent back to sub properly. D, E should be correct.

D. The subscriber code cannot keep up with the messages. If the processing rate of the subscriber (Cloud Functions) is lower than the incoming message rate, it can lead to a backlog of messages. This would result in higher-than-expected message rates, as messages accumulate while waiting to be processed. E. The subscriber code does not acknowledge the messages that it pulls. If messages are not acknowledged properly, Pub/Sub will keep retrying to deliver them, which can lead to the same messages being sent repeatedly. This could also contribute to the perception that the message processing rate is very high. Both of these issues can lead to unanticipated behavior in your message processing pipeline without generating errors that would be logged in Cloud Logging.

The code in the CF can't keep up with the amount of messages, thus C D is a better fit

Ref chatgpt Option C, "Error handling in the subscriber code is not handling run-time errors properly," suggests that the subscriber code may not be correctly handling errors that occur during message processing. If the subscriber code encounters an error that it cannot handle, such as a syntax error or a network issue, it may stop processing messages, leading to a slowdown in message processing. However, the lack of error logs in Cloud Logging suggests that there are no errors being logged, which makes it less likely that this is the primary cause of the observed behavior. Additionally, while incorrect error handling could contribute to the issue, it may not be the primary reason why the message processing rate is much higher than anticipated.

C - as no error shown in Cloud Logging Between D & E, both could lead to the problem. I have worked with lot of PubSub issues, most of them are due to the bottleneck at the code where it takes too long to process 1 message and causes backlog. E could lead to backlog too, but it is too obvious and not likely to happen in reality. However, when I ask AI the same question, it said C and E

Answer D&E I am not in the favour of C, error handling is a side factor but not the primary cause. First check the configuration access. Does subscriber has enough acknowledge policies (option E) Does sub have ability to keep up the message( enough network, cpu and capable codes) (option D) option C is just a part of option D somewhere showing incapable handling

My question is: 'What is the actual problem?' - That there is no logs in Cloud Logging? - That Pub/Sub is having a problem? - Or there an actual problem? - Is there an actual error? So what is Pub/Sub the message processing rate is high...Does that mean there is a problem? Thoughts?

C, E seems correct

D might also be right? Subscriber might not be provisioned enough

C. Error handling in the subscriber code is not handling run-time errors properly. E. The subscriber code does not acknowledge the messages that it pulls.