Quality Engineer

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.