12-prompt specialty benchmark for code comprehension and diagnosis. Spans Python, Bash, JavaScript, SQL, regex, and tool-output interpretation (git, logs, errors). The model is not asked to WRITE code — only to read it, predict its behavior, identify bugs, and interpret output. This is what agents do most often when they encounter code in the wild: routing, triage, and reasoning about someone else's work.

The code prints:

```
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

**Yes, there is a bug.** The second and fourth calls accumulate items into the same list, which is likely unintended.

**The bug:** Mutable default arguments in Python are evaluated once when the function is defined, not each time the function is called. The list `[]` is created at definition time and shared across all calls that don't explicitly provide a `bag` argument.

**Execution trace:**
1. `add_item('apple')` — Uses the default list `[]`, appends `'apple'`, returns `['apple']`. The default list is now `['apple']`.
2. `add_item('bread')` — Uses the same default list (now `['apple']`), appends `'bread'`, returns `['apple', 'bread']`. The default list is now `['apple', 'bread']`.
3. `add_item('cheese', bag=['milk'])` — Uses the explicit list `['milk']`, appends `'cheese'`, returns `['milk', 'cheese']`. The default list is unchanged.
4. `add_item('eggs')` — Uses the default list (still `['apple', 'bread']`), appends `'eggs'`, returns `['apple', 'bread', 'eggs']`.

**Fix:** Use `None` as the default and initialize a new list inside the function:

```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

Output:

```
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

**The bug:** The `bag=[]` default argument is a mutable list created once at function definition time, not once per call. Every call that omits `bag` shares the same list object.

Step by step:

1. `add_item('apple')` — uses the shared default list, appends `'apple'`, returns `['apple']`.
2. `add_item('bread')` — uses the same shared default list (still `['apple']`), appends `'bread'`, returns `['apple', 'bread']`.
3. `add_item('cheese', bag=['milk'])` — caller provides a fresh list `['milk']`, appends `'cheese'`, returns `['milk', 'cheese']`. This call is unaffected by the bug because it doesn't use the default.
4. `add_item('eggs')` — uses the shared default list again (now `['apple', 'bread']`), appends `'eggs'`, returns `['apple', 'bread', 'eggs']`.

**The fix:** Use `None` as the sentinel default and create a new list inside the function body:

```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

This is one of the most well-known Python gotchas. The root cause is that default argument values are evaluated when the function is defined, not when it is called, so a mutable default persists across all calls that rely on it.

**Output:**
```
['apple']
['apple', 'bread']
['milk', 'cheese']
['apple', 'bread', 'eggs']
```

**Bug:** Yes. The function uses a mutable default argument (`bag=[]`).

**Precise description:** In Python, default argument values are evaluated once at function definition time, not at each call. The empty list `[]` is created once and reused across all calls that omit the `bag` argument. Each call appends to this same shared list object, causing items to accumulate unexpectedly.

Calls that pass an explicit `bag` argument (like call 3) use a separate list and don't affect the shared default.

**Fix:**
```python
def add_item(item, bag=None):
    if bag is None:
        bag = []
    bag.append(item)
    return bag
```

This creates a fresh list for each call that doesn't provide `bag`.

The pipeline prints:

```
2
```

**Step-by-step breakdown:**

1. **`ls *.txt`** – The glob `*.txt` expands to match files ending in `.txt` (case-sensitive). From the directory contents, this matches `a.txt` and `b.txt`. The file `e.txt.bak` does not match because it ends in `.bak`, not `.txt`. The file `f.TXT` does not match because the extension is uppercase.

2. **`|` (pipe)** – Since the output is not a terminal, `ls` outputs one filename per line:
   ```
   a.txt
   b.txt
   ```

3. **`wc -l`** – Counts the number of lines, which is **2**.

**Note:** On a case-insensitive filesystem (like macOS default), `f.TXT` would also match and the result would be 3. But the question specifies "Bash without any custom aliases or special shell options," which implies standard Unix behavior where globs are case-sensitive.

The pipeline prints **2**.

`*.txt` is a case-sensitive glob that matches filenames ending in exactly `.txt`:

- **a.txt** — matches
- **b.txt** — matches
- c.py — doesn't end in `.txt`
- d.md — doesn't end in `.txt`
- e.txt.bak — ends in `.bak`, not `.txt`
- f.TXT — Bash globs are case-sensitive by default; `.TXT` ≠ `.txt`

So `ls` produces two lines of output, and `wc -l` counts them.

The pipeline prints: **2**

Here's why:

The glob pattern `*.txt` is case-sensitive in Bash and matches files ending with exactly `.txt` (lowercase).

From the file list:
- `a.txt` — matches (ends with `.txt`)
- `b.txt` — matches (ends with `.txt`)
- `c.py` — no match (wrong extension)
- `d.md` — no match (wrong extension)
- `e.txt.bak` — no match (ends with `.bak`, not `.txt`)
- `f.TXT` — no match (uppercase `.TXT` doesn't match lowercase `.txt`)

So `ls *.txt` outputs two lines:
```
a.txt
b.txt
```

And `wc -l` counts those lines, producing: **2**

The bug is on line 3: **`fetch` is not awaited**.

`fetch` returns a Promise. Without `await`, `response` is assigned that Promise object rather than the actual Response. When the code then attempts `await response.json()`, it fails because Promises do not have a `.json()` method (this would typically throw "TypeError: response.json is not a function").

**Fix:** Add `await` before `fetch`:

```javascript
async function fetchUsers() {
  const response = await fetch('https://api.example.com/users');
  const users = await response.json();
  for (const user of users) {
    console.log(user.name);
  }
}

fetchUsers();
```

**Optional:** Add error handling, since `fetch` does not reject on HTTP error status codes (4xx/5xx). It only rejects on network failure. To catch HTTP errors:

```javascript
async function fetchUsers() {
  const response = await fetch('https://api.example.com/users');
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}: ${response.statusText}`);
  }
  const users = await response.json();
  // ...
}
```

The bug is on line 2: `fetch()` is missing `await`. Without it, `response` is a Promise object, not a Response. Calling `.json()` on a Promise returns `undefined`, so `users` is `undefined`, and `user.name` logs `undefined`.

Fix: add `await` before `fetch`.

```javascript
const response = await fetch('https://api.example.com/users');
```

The existing `await` on `response.json()` is correct, but it never receives a real Response object to await on because the first line already went wrong.

## The Bug

The `fetch()` call is not awaited. `fetch()` returns a Promise, but the code assigns the Promise itself to `response` instead of waiting for it to resolve to the actual Response object.

```javascript
const response = fetch('https://api.example.com/users');  // ❌ response is a Promise
```

When you then call `response.json()`, you're calling `.json()` on a Promise object, not a Response object. A Promise doesn't have a `.json()` method, so this should actually throw a TypeError. However, depending on how the error is handled (or if there's additional code not shown), this can result in `undefined` being logged.

## The Fix

Add `await` before the `fetch()` call:

```javascript
async function fetchUsers() {
  const response = await fetch('https://api.example.com/users');  // ✅ await the fetch
  const users = await response.json();
  for (const user of users) {
    console.log(user.name);
  }
}

fetchUsers();
```

## Why This Matters

`fetch()` is asynchronous and returns a Promise that resolves to a Response object. You need to:

1. **Await the fetch** to get the actual Response object
2. **Await response.json()** to parse the body as JSON

Both operations are asynchronous and require `await`. Without the first `await`, you're trying to call `.json()` on a Promise rather than a Response, which breaks the entire chain.

The regex matches email addresses at **internal.company.com** or **staging.company.com** with strict constraints on the local part (the username before the @):

- Must start with a lowercase letter (`[a-z]`)
- Followed by 2 to 14 lowercase letters, digits, or underscores (`[a-z0-9_]{2,14}`)
- Total length of the username: 3 to 15 characters
- Domain must be exactly `internal.company.com` or `staging.company.com`
- No uppercase letters allowed anywhere

**Three strings that WOULD match:**

1. `abc@internal.company.com`
2. `user_123@staging.company.com`
3. `a12345678901234@internal.company.com` (15-character username: 1 letter + 14 characters)

**Three strings that would NOT match:**

1. `Abc@internal.company.com` (starts with uppercase A)
2. `ab@staging.company.com` (username too short—only 2 characters)
3. `abc@production.company.com` (wrong subdomain—must be internal or staging)

The pattern matches email-style strings with these constraints:

- Must start with a lowercase letter (`[a-z]`).
- Followed by 2 to 14 characters, each being a lowercase letter, digit, or underscore (`[a-z0-9_]{2,14}`).
- Then a literal `@`.
- Then either `internal.company.com` or `staging.company.com`.
- Nothing before or after (`^` and `$` anchors).

The local part (before the `@`) is therefore 3 to 15 characters total: one mandatory letter plus 2–14 more. It cannot start with a digit or underscore. The domain must be exactly one of the two listed subdomains — no other subdomains of `company.com` will match.

---

**Three strings that WOULD match:**

1. `alice@internal.company.com`
2. `dev_user123@staging.company.com`
3. `b_9x@internal.company.com`

**Three strings that would NOT match:**

1. `Alice@internal.company.com` — starts with an uppercase letter, which `[a-z]` rejects.
2. `ab@staging.company.com` — local part is only 2 characters, below the minimum of 3.
3. `alice@prod.company.com` — the subdomain `prod` is not `internal` or `staging`.

## What This Regex Matches

This regex validates email addresses with a specific format for internal company use. It matches emails where:

1. The username (before @) starts with a lowercase letter, followed by 2–14 characters that can be lowercase letters, digits, or underscores (total username length: 3–15 characters)
2. The domain is either `internal.company.com` or `staging.company.com`
3. Nothing else appears before or after (the `^` and `$` anchors enforce exact matching)

---

## Three Strings That WOULD Match

1. `abc@internal.company.com`
2. `john_doe123@staging.company.com`
3. `a_1@internal.company.com`

---

## Three Strings That Would NOT Match

1. `ABC@internal.company.com` — uppercase letters in the username are not allowed
2. `ab@staging.company.com` — username is only 2 characters (minimum is 3)
3. `abc@production.company.com` — "production" is not an allowed subdomain (only "internal" or "staging")

ERROR: could not parse JSON: Extra data: line 1 column 79 (char 78)

The query is not correct. It will always return zero rows, regardless of the data.

The problem is the `INNER JOIN`. An inner join only returns rows that have a match in both tables. If a customer has never placed an order, they have no matching row in `orders`, so that customer is eliminated from the result set entirely — before the `WHERE` clause ever runs. The condition `o.id IS NULL` can never be satisfied because `INNER JOIN` guarantees that every returned row has a non-null match in `orders`.

**Fix: use a `LEFT JOIN` instead.**

```sql
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;
```

A `LEFT JOIN` returns all customers, and where there is no matching order, the columns from `orders` are filled with `NULL`. The `WHERE o.id IS NULL` filter then correctly selects only those customers with no orders.

**Two other correct alternatives:**

Using `NOT EXISTS`:

```sql
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1 FROM orders o WHERE o.customer_id = c.id
);
```

Using `NOT IN`:

```sql
SELECT c.id, c.name
FROM customers c
WHERE c.id NOT IN (
  SELECT customer_id FROM orders WHERE customer_id IS NOT NULL
);
```

The `NOT IN` variant requires the `WHERE customer_id IS NOT NULL` guard because `NOT IN` with a null in the subquery results in an empty result set (a well-known SQL pitfall). `NOT EXISTS` does not have this problem. Among the three, `LEFT JOIN ... IS NULL` and `NOT EXISTS` are the most commonly recommended; performance between them is typically equivalent in modern databases since the optimizer recognizes them as the same operation.

The query is **incorrect**. It will return **zero rows**, not the customers who have never placed an order.

## The Problem

The issue is the **INNER JOIN**. An INNER JOIN only returns rows where there's a match in both tables. If a customer has no orders, there's no matching row in the `orders` table, so that customer is excluded from the result set entirely—before the WHERE clause is even evaluated.

This means `o.id IS NULL` can never be true, because rows where `o.id` would be NULL are never produced by the INNER JOIN in the first place.

## The Fix

Use a **LEFT JOIN** instead:

```sql
SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE o.id IS NULL;
```

This works because:
1. LEFT JOIN keeps all customers, even those without matching orders
2. For customers without orders, the `orders` columns (including `o.id`) are filled with NULL
3. The WHERE clause then filters to only those NULL rows—the customers with no orders

## Alternative Approaches

You could also write this using a subquery:

```sql
-- Using NOT EXISTS (generally preferred)
SELECT c.id, c.name
FROM customers c
WHERE NOT EXISTS (
    SELECT 1 FROM orders o WHERE o.customer_id = c.id
);

-- Using NOT IN (works but be careful with NULLs in customer_id)
SELECT c.id, c.name
FROM customers c
WHERE c.id NOT IN (
    SELECT customer_id FROM orders WHERE customer_id IS NOT NULL
);
```

The LEFT JOIN and NOT EXISTS approaches are both efficient and clear. NOT EXISTS is often preferred for readability when the intent is "find rows without matching children."

The code prints:

```
[2, 2, 2]
```

**Why:** Python closures capture **variables by reference**, not by value. Each lambda captures the variable `i` itself, not its value at the time the lambda was created. When the lambdas are called after the loop finishes, `i` equals `2` (its final value), so all three lambdas return `2`.

It prints `[2, 2, 2]`.

The lambdas capture the **variable** `i`, not its value at the time of creation. By the time the loop finishes, `i` is `2` (the last value from `range(3)`). When each lambda is called in the list comprehension, they all look up the same `i` and find `2`.

If you wanted `[0, 1, 2]`, you'd need to bind the current value with a default argument:

```python
lambda i=i: i
```

This works because default argument values are evaluated once at function definition time, not at call time.

The code prints:

```
[2, 2, 2]
```

This is a classic Python closure gotcha. The issue is that the lambda functions capture the variable `i` by reference, not by value. All three lambdas reference the same `i` from the enclosing scope.

After the loop completes, `i` equals 2 (the last value from `range(3)`). When each lambda is called later in the list comprehension, they all read the current value of `i`, which is 2.

To get `[0, 1, 2]` instead, you'd need to capture the value at definition time, typically using a default argument:

```python
funcs.append(lambda i=i: i)
```

**State of the working directory:**

You are on the `feature/auth-v2` branch with 2 commits that exist locally but haven't been pushed to the remote yet. Your working directory has three categories of uncommitted modifications:

1. **Staged for commit**: You've modified `src/auth.ts` and created a new file `src/oauth.ts`, and both are in the staging area (index), ready to be included in the next commit.

2. **Modified but not staged**: You've made additional changes to `src/auth.ts` beyond what's staged, and you've deleted `src/legacy.ts` — neither of these are staged yet, so they won't be included in the next commit unless you add them.

3. **Untracked**: There's a new file `tmp.log` that Git isn't tracking at all.

Note that `src/auth.ts` appears in both staged and unstaged sections, meaning it has some changes staged and other changes not yet staged.

**Recommendation to discard all local changes:**

To completely wipe all uncommitted changes and get to a clean working directory (while keeping those 2 local commits):

```bash
git reset --hard && git clean -fd
```

This will:
- `git reset --hard`: Discard all staged and unstaged changes, reverting modified files to match HEAD
- `git clean -fd`: Remove all untracked files (`tmp.log`) and any untracked directories

If you also want to discard the 2 local commits and match origin exactly:

```bash
git reset --hard origin/feature/auth-v2 && git clean -fd
```

**Warning:** These commands are destructive and cannot be undone. The first preserves your 2 unpushed commits; the second deletes them along with the working directory changes.

**Current state:**

You're on the `feature/auth-v2` branch, 2 commits ahead of the remote tracking branch. Beyond those unpushed commits, there are three layers of local changes:

1. **Staged changes** — `src/auth.ts` has modifications staged for the next commit, and a new file `src/oauth.ts` is staged.
2. **Unstaged changes** — `src/auth.ts` has further modifications that haven't been staged (on top of the already-staged changes to the same file), and `src/legacy.ts` has been deleted from the working tree but that deletion hasn't been staged.
3. **Untracked file** — `tmp.log` exists in the working directory but isn't tracked by git.

**To discard everything and get back to a clean state:**

```bash
git checkout origin/feature/auth-v2 -- .   # reset working tree and index to match the remote branch
git clean -fd                               # remove untracked files (deletes tmp.log)
```

This will throw away the 2 unpushed commits, all staged and unstaged modifications, and the untracked file. The working directory will match `origin/feature/auth-v2` exactly.

If you want to keep the 2 local commits but still discard the staged/unstaged/untracked changes, replace the first command with:

```bash
git reset --hard HEAD
```

That resets the index and working tree to the tip of your current branch (preserving the 2 commits) and then `git clean -fd` handles the untracked file.

## State of the Working Directory

You're on branch `feature/auth-v2` with **2 local commits** that haven't been pushed to the remote yet.

Your changes are in three states:

1. **Staged (ready to commit)**: `src/auth.ts` was modified and `src/oauth.ts` was created, then added to the staging area.

2. **Unstaged modifications**: After staging, you made more changes to `src/auth.ts` and deleted `src/legacy.ts`. These won't be included in the next commit unless you stage them.

3. **Untracked**: `tmp.log` exists but git isn't tracking it.

Note that `src/auth.ts` appears in both staged and unstaged sections — the version you staged differs from what's currently in your working directory.

## To Discard All Local Changes

Run these commands in order:

```bash
git reset --hard origin/feature/auth-v2
git clean -fd
```

**What this does:**
- `git reset --hard origin/feature/auth-v2` — Discards the 2 local commits, unstage everything, and reverts all tracked files to match the remote branch
- `git clean -fd` — Removes untracked files and directories (like `tmp.log`)

**Warning:** This is irreversible. Any work in those 2 commits and all modifications will be permanently lost. If there's anything you might want to keep, create a backup branch first with `git branch backup-feature-auth-v2`.

**What happened:**

The application started normally and was running for about 33 minutes before slow queries began appearing. The same query (`SELECT * FROM events WHERE user_id = ?`) progressively degraded in performance from 2.1 seconds to 8.2 seconds over a 16-minute window. As these queries occupied database connections for longer durations, the connection pool (size 20) became fully exhausted, causing subsequent requests to wait for available connections and eventually timeout. After five unrecoverable errors (likely the connection pool exhaustion errors and timeouts), the server shut down.

**Most likely root cause:**

Missing database index on the `user_id` column of the `events` table. Without an index, the query performs a full table scan. As the `events` table grew over time (between 01:47 and 02:03), each execution scanned increasingly more data, explaining the escalating query times (2.1s → 4.7s → 8.2s). Eventually, the queries became so slow that all 20 connections were occupied simultaneously, starving the pool and causing cascading failures.

**Secondary possibility:** The query returns large result sets (due to `SELECT *`) that are growing over time, compounding the problem even with an index present. However, the progressive degradation pattern strongly suggests missing index as the primary issue.

## What Happened

The server started normally at 01:14, then degraded over roughly an hour until it became unresponsive and shut itself down.

## Sequence of Events

1. **01:47–02:03** — The same query (`SELECT * FROM events WHERE user_id = ?`) gets progressively slower: 2.1s → 4.7s → 8.2s. This is exponential growth, not random variance.

2. **02:12:09** — The connection pool (20 connections) is fully consumed. All connections are held and none are being returned.

3. **02:12:15–02:12:20** — Incoming requests pile up, wait 30 seconds, and time out. They can't get a connection because the pool is saturated.

4. **02:13:01** — Pool still exhausted. Nothing has recovered.

5. **02:13:45** — The server hits its unrecoverable-error limit and kills itself.

## Most Likely Root Cause

A **missing or inadequate index on `events.user_id`**, causing a full table scan that degrades as the `events` table grows.

The progressive slowdown is the key signal: the same query takes 2s, then 5s, then 8s over the span of an hour. This is consistent with a table scan on a growing table — likely rows are being inserted continuously (it is an `events` table), and without an index on `user_id`, every query must scan more rows as the table grows.

The cascading failure then follows mechanically:

- Slow queries hold connections for longer.
- As queries get slower, connections accumulate and aren't returned to the pool fast enough.
- New requests arrive, grab the remaining connections, and those also get stuck on slow queries.
- Pool exhaustion → timeouts → fatal shutdown.

**The fix** would be `CREATE INDEX idx_events_user_id ON events(user_id)`. A secondary concern would be whether `SELECT *` is necessary — if the table has wide rows, returning all columns amplifies the cost — but the missing index is the primary issue.

**What happened:**

The server experienced a cascading failure over approximately one hour:

1. **Startup (01:14:22)**: Server started normally, connected to the database pool, began listening on port 8080.

2. **Degradation phase (01:47 - 02:03)**: Three warnings show the same query (`SELECT * FROM events WHERE user_id = ?`) getting progressively slower: 2.1s → 4.7s → 8.2s. Each slow query held a database connection open longer.

3. **Collapse (02:12 - 02:13)**: All 20 connections in the pool were consumed by these hanging queries. New requests couldn't acquire connections, resulting in 30-second timeouts. After 5 unrecoverable errors, the server shut down.

**Most likely root cause:**

**Missing index on `user_id` column in the `events` table.**

The query `SELECT * FROM events WHERE user_id = ?` is performing full table scans. As the `events` table grew, scan times increased, causing connections to remain occupied longer. This created a feedback loop: slower queries → connections held longer → pool exhaustion → timeouts → server failure.

**Fix:**

```sql
CREATE INDEX idx_events_user_id ON events(user_id);
```

Additionally, consider:
- Avoiding `SELECT *` and fetching only needed columns
- Increasing the connection pool size as a temporary mitigation
- Adding query timeouts to prevent individual queries from monopolizing connections indefinitely

No, they are not semantically equivalent.

There is one difference: **the type of the `port` value**.

*   In the YAML, `port: 5432` is an **integer** (unquoted numeric literal).
*   In the JSON, `"port": "5432"` is a **string** (quoted literal).

All other values have equivalent types (`host`, `name`, and the elements of `options` are strings; `timeout` is a number in both). The reordering of keys within the `database` object (host/name/port vs. host/port/name) does not affect semantic equivalence, as both YAML and JSON object key order is conventionally insignificant.

No, they are not semantically equivalent. There is one difference:

**`port` has a different type.**

In the YAML, `port: 5432` is an **integer** (YAML parses unquoted numerics as integers). In the JSON, `"port": "5432"` is a **string** (the value is wrapped in quotes). This matters whenever the consuming code distinguishes between types — for example, a configuration validator that expects an integer would accept the YAML but reject the JSON, and equality checks or strict comparisons would fail.

Key ordering (host/port/name/options/timeout vs host/name/port/options/timeout) differs between the two, but that is not a semantic difference for maps/objects — order of keys in a mapping is insignificant in both YAML and JSON semantics unless a specific application imposes ordering requirements.

That is the only semantic difference.

No, they are not semantically equivalent. There is one difference:

**port type mismatch:**
- YAML: `port: 5432` — parsed as a **number** (integer)
- JSON: `"port": "5432"` — parsed as a **string**

Everything else matches:
- `host`: both are the string "localhost"
- `name`: both are the string "helmdb"
- `options`: both are arrays containing ["ssl", "pooling"] in the same order
- `timeout`: both are the number 30

The key ordering differs (YAML has port before name, JSON has name before port), but that does not affect semantics in standard parsers.

Whether the port type difference matters depends on the consumer. Some systems coerce strings to numbers automatically; others may fail validation or behave differently if they expect a specific type.

The main bug is **unquoted variable expansion causing word splitting and glob expansion**, combined with the **lack of nullglob handling** when no `.tmp` files exist.

Problems in the original:
1. **Unquoted `$DIR`**: If the directory path contains spaces, word splitting breaks the glob.
2. **Unquoted `$f`**: If a filename contains spaces, `rm` receives it as multiple arguments.
3. **No nullglob**: If no `.tmp` files exist, the loop iterates once with the literal string `*.tmp`, causing `rm` to fail or delete the wrong thing. Worse, if `$DIR` is empty, the glob becomes `/*.tmp` which is dangerous.

Fixed version:

```bash
#!/bin/bash
DIR="$1"

# Validate input
if [[ -z "$DIR" ]]; then
  echo "Usage: $0 <directory>" >&2
  exit 1
fi

if [[ ! -d "$DIR" ]]; then
  echo "Error: '$DIR' is not a directory" >&2
  exit 1
fi

# Enable nullglob so the loop doesn't run if no matches
shopt -s nullglob

for f in "$DIR"/*.tmp; do
  rm -- "$f"
done
```

Alternative using `find` (handles directories with newlines in names):

```bash
#!/bin/bash
DIR="${1:?Usage: $0 <directory>}"

[[ -d "$DIR" ]] || { echo "Error: '$DIR' not a directory" >&2; exit 1; }

find "$DIR" -maxdepth 1 -type f -name '*.tmp' -delete
```

Or for older `find` without `-delete`:

```bash
find "$DIR" -maxdepth 1 -type f -name '*.tmp' -exec rm -f -- {} +
```

Several bugs, in order of severity:

1. **Unquoted `$DIR` in the glob**: If the directory path contains spaces or glob characters, word splitting and globbing will mangle it before `for` ever sees the files. Same problem with `rm $f` — an unquoted `$f` with spaces will be split into multiple arguments, potentially deleting the wrong files.

2. **No check that files actually exist**: When `*.tmp` matches nothing, the glob is left unexpanded and the loop iterates once with the literal string `$DIR/*.tmp`. `rm` then tries to delete a file by that name, producing an error (or worse, if some variant of `rm` or a future edit adds `-f`, it silently succeeds on a weird path).

3. **No validation of `$1`**: If the user omits the argument, `$DIR` is empty and the glob becomes `/*.tmp`, operating on root.

4. **No `rm -f`**: A read-only or missing file will produce an error and abort the loop.

Fixed version:

```bash
#!/bin/bash
set -euo pipefail

DIR="${1:?Usage: $0 <directory>}"

if [ ! -d "$DIR" ]; then
  echo "Error: '$DIR' is not a directory" >&2
  exit 1
fi

shopt -s nullglob
tmp_files=("$DIR"/*.tmp)
shopt -u nullglob

if [ ${#tmp_files[@]} -eq 0 ]; then
  echo "No .tmp files found in '$DIR'"
  exit 0
fi

rm -f -- "${tmp_files[@]}"
```

Key changes:

- **All expansions are double-quoted** — no word splitting or globbing on paths with spaces/special characters.
- **`nullglob`** makes the glob expand to nothing when there are no matches, avoiding the phantom-iteration bug. It's set only for the assignment and unset immediately after, since leaving it on globally can break things.
- **Array + single `rm`** instead of a loop — fewer process spawns, atomic error handling, and `"${tmp_files[@]}"` correctly passes each filename as a separate argument even with spaces.
- **`--`** prevents a filename starting with `-` from being interpreted as an option to `rm`.
- **Input validation** with `${1:?}` and a directory check.

## Bugs in the Script

1. **Unquoted variables** — `$DIR` and `$f` are unquoted. If the directory path or filenames contain spaces, word splitting breaks the script.

2. **No argument validation** — If no argument is given, `$DIR` is empty and the script deletes `*.tmp` in the current directory.

3. **No directory check** — The script doesn't verify that the argument is actually a directory.

4. **Glob doesn't expand when no matches** — If there are no `.tmp` files, the literal string `*.tmp` is passed to `rm`, causing an error.

5. **Filenames starting with `-`** — A file like `-dangerous.tmp` could be interpreted as an `rm` flag.

6. **Filenames with newlines** — The `for` loop splits on whitespace, so filenames with newlines break into multiple iterations.

## Fixed Version

```bash
#!/bin/bash
DIR="$1"

# Check if directory argument was provided
if [ -z "$DIR" ]; then
  echo "Error: No directory specified" >&2
  exit 1
fi

# Check if directory exists and is a directory
if [ ! -d "$DIR" ]; then
  echo "Error: '$DIR' is not a valid directory" >&2
  exit 1
fi

# Enable nullglob so the loop doesn't run if no matches
shopt -s nullglob

# Use find to handle all special characters safely
find "$DIR" -maxdepth 1 -type f -name '*.tmp' -print0 | while IFS= read -r -d '' f; do
  rm -- "$f"
done
```

Or a simpler version if you don't need newline-safe handling:

```bash
#!/bin/bash
DIR="$1"

if [ -z "$DIR" ]; then
  echo "Error: No directory specified" >&2
  exit 1
fi

if [ ! -d "$DIR" ]; then
  echo "Error: '$DIR' is not a valid directory" >&2
  exit 1
fi

shopt -s nullglob

for f in "$DIR"/*.tmp; do
  rm -- "$f"
done
```

**Key fixes:** quote all variables, validate the argument, use `nullglob` to handle empty matches, and use `--` with `rm` to prevent flag injection. The `find` version is safest for arbitrary filenames.

ERROR: could not parse JSON: Extra data: line 1 column 79 (char 78)

The response is unambiguous:

**What it tells you:** The request included a bearer access token in the `Authorization` header, but that token has expired. The server recognized the token as structurally valid (it's not malformed or revoked — it simply reached its expiration time), so authentication failed due to token age, not due to bad credentials.

**What the client should do:** Use its refresh token (obtained alongside the original access token) to request a new access token from the token endpoint, then retry the original request with the new token. This is the standard OAuth 2.0 flow — access tokens are short-lived by design, and refresh tokens exist precisely for this scenario.

If the client has no refresh token, or the refresh token has also expired or been revoked, the user must re-authenticate (go through the authorization flow again) to get a fresh pair of tokens.

One thing worth noting: the `WWW-Authenticate` header is doing its job correctly per RFC 6750 and RFC 7235, signaling both the error code (`invalid_token`) and a human-readable description. A well-written client can parse this header programmatically to distinguish "expired" from "revoked" or "malformed" and branch accordingly.

This is a standard OAuth 2.0 Bearer token authentication failure. Here's what each part tells you:

**What the response means:**

| Element | Meaning |
|---------|---------|
| `401 Unauthorized` | The request lacks valid authentication credentials |
| `WWW-Authenticate: Bearer` | The API expects OAuth 2.0 Bearer token authentication |
| `error="invalid_token"` | The token itself is rejected (not missing) |
| `error_description="The access token expired"` | The specific reason: the token's validity period has ended |

**What the client should do:**

1. **Do not retry with the same token** — it will fail again.

2. **Obtain a fresh access token:**
   - If you have a **refresh token**, use it to request a new access token from the token endpoint.
   - If you don't have a refresh token (or it's also expired), re-authenticate the user (e.g., redirect through the OAuth authorization flow or prompt for credentials).

3. **Retry the original request** with the new access token in the `Authorization` header:
   ```
   Authorization: Bearer <new_access_token>
   ```

**Optional but recommended:**
- Implement automatic token refresh logic before expiration (check `expires_in` when you receive a token).
- Handle this error gracefully in your client code by catching 401s with `invalid_token` and triggering the refresh flow transparently.

The function has **no bugs** in Python 3. It correctly computes the median for both odd and even length sequences and raises `ValueError` for empty sequences.

**Logic verification:**
- Empty check: `if not numbers` correctly catches empty lists, tuples, and other falsy sequences.
- Sorting: `sorted()` creates a new sorted list without mutating the input.
- Odd length: `sorted_nums[mid]` returns the middle element (e.g., index 2 for length 5).
- Even length: `(sorted_nums[mid - 1] + sorted_nums[mid]) / 2` averages the two central elements (e.g., indices 1 and 2 for length 4).

**Note:** In Python 2, the `/` operator performs integer division, which would truncate the result for even-length lists of integers (e.g., median of `[1, 2]` returns `1` instead of `1.5`). If Python 2 compatibility is required, change `/ 2` to `/ 2.0`.

No bugs. The function correctly:

1. Raises `ValueError` for an empty input.
2. Sorts the numbers.
3. Returns the middle element for odd-length lists (`n // 2` gives the correct index for 0-based indexing).
4. Returns the average of the two middle elements for even-length lists (`mid - 1` and `mid` are the correct pair).

One minor note: for even-length lists, the result is a `float` (due to `/ 2`), while odd-length lists return whatever type the elements are (likely `int` if the input contains ints). This isn't a bug, but it's a type inconsistency worth being aware of. If consistent `float` output is desired, you could wrap the odd-length return in `float()`.

No bugs.

The function correctly implements the median calculation:

1. **Empty sequence handling:** Properly raises `ValueError` for empty input.
2. **Sorting:** Creates a sorted copy without mutating the original list.
3. **Odd-length case:** Returns the middle element at index `n // 2`.
4. **Even-length case:** Returns the average of the two middle elements at indices `mid - 1` and `mid`.

The index logic is correct. For example:
- `[1, 3, 5]` (n=3, mid=1): returns `sorted_nums[1]` = 3 ✓
- `[1, 2, 3, 4]` (n=4, mid=2): returns `(sorted_nums[1] + sorted_nums[2]) / 2` = 2.5 ✓

One minor note: the function returns a `float` for even-length lists (due to `/ 2`), which is standard statistical behavior. If you needed integer output for integer inputs with even length, you'd need to adjust, but as written, this is correct.