6.3 Secure Search and Minimal Reproduction

Prerequisites: Understanding Errors, Log Basics

Estimated time: 15 minutes

You are ready to continue when: you can construct a sanitized query and deliver a minimal reproduction that others can run from a clean directory.

Logs preserve failure evidence but do not necessarily reveal the root cause. Before searching, keep the original records in a controlled location: search boxes, public issues, and chat windows are not default destinations for production logs.

Searchable Errors

Consider this database error:

org.postgresql.util.PSQLException:
ERROR: duplicate key value violates unique constraint "users_pkey"

If staring at duplicate for half an hour produces no progress, search for evidence; do not treat production logs as public text.

First Step: Creating a Shareable Local Copy

Keep the original error in a controlled location. Make a copy, then delete or replace:

• Passwords, tokens, API keys, cookies, and session identifiers;
• Database connection strings, private repository addresses, and internal hostnames;
• Customer data, personal information, emails, phone numbers, and real business numbers;
• Local usernames, absolute paths, and internal IP addresses;
• Irrelevant request bodies, timestamps, random IDs, and stack frames.

Use placeholders like <ACCESS_TOKEN> and <USER_ID> instead of blurring values to the point where the field's meaning is unclear. Keeping a few characters at either end can still reveal sensitive information.

Step 2: Construct Queries That Target Similar Issues

Start with a stable fragment like this:

PSQLException duplicate key value violates unique constraint PostgreSQL 17 JDBC

Operations:

1. Retain the exception type and general message;
2. Remove the specific ID, path, time, and line number from each change;
3. Add only the relevant language, framework, and exact version;
4. Verify against the official documentation and project Issue for the current version, then refer to community answers if necessary;
5. Validate in an isolated environment with a minimal reproducible case; avoid executing unfamiliar delete, permission, or installation commands directly.

This database message confirms a unique constraint violation, but it does not prove whether it's due to duplicate submissions, sequence desynchronization, primary key generation errors, or residual test data. Search results suggest hypotheses.

Third Step: Reduce 500 Lines to Runnable Evidence

Sending Spring Boot, PostgreSQL, a connection pool, routing, and caching together forces the recipient to set up the whole project before reaching the failure. Removing unrelated components reduces that setup work.

A usable minimal reproduction includes:

Content	How detailed should it be
Environment	Exact versions of operating system, runtime, framework, and related dependencies
Files	Only the content needed to trigger the issue, along with directory structure
Preparation Steps	Complete commands starting from a clean directory
Input	Minimum, fictional, or de-identified data
Reproduction Steps	Each step should be replicable, with instructions for the working directory
Expected Result	Specific to output, status, or return value
Actual Result	Complete but de-identified errors and exit codes
Scope Information	The last normal version, the first abnormal version, and excluded items

How to Reduce Without Also Removing Bugs

1. First, stabilize and reproduce the original phenomenon in a copy.
2. Fix one command and one input.
3. Remove one module, configuration, or dependency at a time.
4. Run the same test each time and record whether the phenomenon can still be reproduced.
5. Use a mock implementation to replace databases or APIs; if the real boundary is the condition, keep it and provide a safe local alternative environment.
6. When a reduction stops reproducing the failure, undo that last reduction. Deliver the version that still fails.

The minimum is not "just one line," and completeness does not mean "the entire repository." The goal is to retain all conditions that cause the phenomenon while eliminating other variables.

A Deliverable README Template

# Reproduction: concise problem name

## Environment
- OS:
- Runtime:
- Framework / dependency versions:

## Run
1. From this directory, run: `...`
2. Observe the process exit code: `...`

## Expected
...

## Actual
...

## Notes
- Last known good version:
- First known bad version:
- Variables already ruled out:

Don't just post screenshots. Text is searchable, copyable, and accessible to assistive technologies; screenshots can supplement interface states, but they cannot replace commands, text errors, and files.

Pre-Question Safety Check

• [ ] Example does not contain real keys, cookies, or connection strings;
• [ ] User and customer data have been replaced with fictional data;
• [ ] Private URLs, hostnames, and paths have been replaced;
• [ ] The issue can still be reproduced in a new directory or new container;
• [ ] Lock files or dependency version information have been included;
• [ ] Expected versus actual results are clearly separated;
• [ ] You have not assumed "it's definitely a bug in some library," only stated the observed results.

Before Leaving This Page

• Rewrite the example database error into a search query without project identifiers;
• Remove variables one by one from an existing problem copy, keeping records of each run;
• Allow another person to reproduce the issue just by looking at the README;
• Be able to explain that "search results are candidate causes, not diagnostic conclusions."

The theory is in place. Now capture exit codes, verify stack frames, check logs, and handle a commonly misstated Java dependency case.

→ Next: Comprehensive Troubleshooting Exercise