Quality Engineer

hunt a bug using one of the available personas

I have enough to report a validated, high-confidence finding. I hunted the comment-submission flow in PostDetailActivity as The Repeater — the flaky-network user whose behaviour is "it failed, so I hit it again."

QUALITY ENGINEER - BUG HUNT App: BlogApp (Android / Firebase Realtime DB) Mode: Bug hunt Personas: The Repeater (flaky-network retrier) Date: 2026-06-18 Result: 1 validated bug (2 facets, same root behaviour)

[1] Failed comment submit leaves the user stuck, and genuine retries create duplicates Severity: High Persona: The Repeater — works on bad signal; when a write "fails" they retry. This flow both blocks the retry AND duplicates on retry. Area: Activities/PostDetailActivity.java — add-comment flow Technique: Error Guessing, Idempotency Thinking, Reliability/Resilience

Summary: On a failed comment write the "Add Comment" button is never re-shown, trapping the user; and because each tap calls a fresh push(), any real network retry writes a duplicate comment.

Why: Two coupled defects in the same handler:

        (a) Recoverability — the button is hidden on click and only
            restored in the SUCCESS callback. The failure callback shows
            a toast but never restores visibility, so after one failed
            send the user cannot resend the comment they just typed
            without leaving and re-entering the screen.

        (b) Server-side idempotency — push() is called fresh inside
            every onClick, minting a new unique key per attempt. There is
            no idempotency key or natural unique constraint, so a request
            that times out on the client but actually committed will be
            written a second time on retry → duplicate comments.

Evidence: PostDetailActivity.java:87-116 btnAddComment.setOnClickListener(... { btnAddComment.setVisibility(View.INVISIBLE); // hidden on click DatabaseReference commentReference = firebaseDatabase.getReference(COMMENT_KEY) .child(PostKey).push(); // new key EVERY tap ... commentReference.setValue(comment) .addOnSuccessListener(... { btnAddComment.setVisibility(View.VISIBLE); // restored only on success }) .addOnFailureListener(... { showMessage("fail to add comment : "+e.getMessage()); // <-- button NOT restored; no rollback; no dedupe });

Steps to reproduce: Facet (a): 1. Open a post, type a comment, go offline / drop signal. 2. Tap "Add Comment". Write fails; toast appears. 3. Button has vanished — no way to resend without re-opening the post. Facet (b): 1. On a slow/flaky connection, tap "Add Comment". 2. Client reports failure/timeout but the write reaches the server. 3. User (or app on next session) retries → two identical comments.

Expected: A failed submit restores the button so the user can retry; a retry of a write that already committed produces exactly one comment. Actual: Failed submit permanently hides the button; genuine retries each create a new node → duplicate comments.

Requirement: Gap — not specified. Suggested test:

• Unit/UI (Robolectric/Espresso): mock setValue() to invoke the failure listener; assert btnAddComment.getVisibility() == VISIBLE afterwards.
• Integration: simulate commit-then-timeout; assert only one comment node exists for the post after a retry. Suggested fix:
• In addOnFailureListener, restore btnAddComment to VISIBLE (mirror the success path) — ideally via a finally-style shared callback.
• Compute the push key ONCE before the attempt (or use a content/client idempotency key) and reuse it across retries so a replay overwrites rather than appends.