Java

A route ID is only an identifier; it is not proof of permission. Authenticate the caller, load the target resource, and authorize the caller against that specific customer before returning data. Example: var customer = await db.Customers .SingleOrDefaultAsync(x => x.Id == customerId, ct); if (customer is null) return NotFound(); var decision = await authorizationService.AuthorizeAsync( User, customer, "ReadCustomerOrders"); if (!decision.Succeeded) return Forbid(); var orders = await db.Orders .Where(x => x.CustomerId == customerId) .ToListAsync(ct); return Ok(orders); The policy must use trusted server-side identity/relationships, never a client-supplied isAdmin property. Add tests for own-customer access, another customer's ID, unauthenticated access and a missing customer.

Pass the CancellationToken to HTTP and stream-reading APIs, validate the status before processing, and configure an appropriate timeout. Example: using var response = await httpClient.GetAsync( "/reports", HttpCompletionOption.ResponseHeadersRead, cancellationToken); response.EnsureSuccessStatusCode(); await using var stream = await response.Content.ReadAsStreamAsync( cancellationToken); using var reader = new StreamReader(stream); var text = await reader.ReadToEndAsync(cancellationToken); For very large data I would deserialize or process the stream incrementally instead of reading all of it into memory. Caller cancellation should propagate; timeouts and transient HTTP failures should be handled separately, with bounded retries only when retrying is safe.

Normalize valid text values and report invalid records explicitly. Example: from collections import Counter def count_event_types(events): counts = Counter() invalid_count = 0 for event in events: raw_type = event.get("type") if not isinstance(raw_type, str) or not raw_type.strip(): invalid_count += 1 continue counts[raw_type.strip().casefold()] += 1 return counts, invalid_count The sample yields login: 2, logout: 1, and one invalid record. Tests should cover missing keys, None, empty strings, non-string values, casing, whitespace and empty input. In production I would expose invalid_count as a metric instead of silently hiding malformed records.

Use the department table as the preserved side of a LEFT JOIN and count a nullable employee key. SELECT d.DepartmentId, d.DepartmentName, COUNT(e.EmployeeId) AS EmployeeCount FROM dbo.Departments AS d LEFT JOIN dbo.Employees AS e ON e.DepartmentId = d.DepartmentId GROUP BY d.DepartmentId, d.DepartmentName ORDER BY d.DepartmentName; LEFT JOIN preserves departments with no match. COUNT(e.EmployeeId) returns zero for those rows because the joined employee key is NULL. COUNT(*) would count the unmatched outer row and incorrectly give one. NULL DepartmentId values do not match a department under ordinary equality joins.

Concatenation can let input modify the SQL syntax. Use a parameterized command so the database treats the email as data. Example: await using var command = connection.CreateCommand(); command.CommandText = "SELECT UserId, Email FROM dbo.Users WHERE Email = @email"; var parameter = command.CreateParameter(); parameter.ParameterName = "@email"; parameter.Value = email; command.Parameters.Add(parameter); await using var reader = await command.ExecuteReaderAsync(cancellationToken); Also validate expected input shape, use least-privileged DB credentials, select only required columns and add tests with quotes or injection-like strings. Validation alone is not a substitute for parameterization.

List<T> is not thread-safe for concurrent writes. Multiple tasks may interfere with its internal state, causing lost or inconsistent results. For unordered output, a ConcurrentBag or a channel can be appropriate: var results = new ConcurrentBag<ProcessedFile>(); Parallel.ForEach(files, file => { results.Add(Process(file)); }); A ConcurrentBag does not guarantee input order. If order matters, assign each input an index and write to a pre-sized result array at that index, or use a parallel API that preserves input ordering. Define whether one failure cancels the batch or is recorded per file, and test with many items repeatedly.

The naive recursion repeats the same subproblems and takes exponential time, approximately O(2^n). An iterative solution has linear time and constant extra space: def fib(n): if n < 0: raise ValueError("n must be non-negative") previous, current = 0, 1 for _ in range(n): previous, current = current, previous + current return previous Time is O(n) and extra space is O(1). Memoization is also O(n) time but requires O(n) cache space and may still encounter recursion depth limits. Tests should include n=0, n=1, known small values and invalid negative input.

At the request boundary, validate positive IDs, a non-empty bounded items array, positive quantities and valid field shapes. Return a 400 response for malformed input. In the service layer, verify that the caller can order for the customer, products exist and are active, stock is sufficient, and prices/discounts come from trusted server-side data rather than the client. In persistence, create the order and line items atomically in a transaction. Use appropriate concurrency controls to prevent overselling, and use foreign keys and constraints where applicable. Roll back on failure. Test malformed payloads, unauthorized customers, out-of-stock products, concurrent purchases and transaction rollback.

A read-then-write flow lets both transactions observe stock as one and both continue. Enforce the invariant in an atomic database update instead. UPDATE dbo.Products SET Stock = Stock - 1 WHERE ProductId = @productId AND Stock > 0; Check the affected-row count. Zero updated rows means the item was unavailable. Run the stock change and order insert in one transaction so a failed order insert rolls back the stock decrement. For more complex rules, consider optimistic concurrency tokens or suitable isolation/locking. A prior application-side check alone is insufficient.

The request order is not guaranteed to match response order. Abort the obsolete request during effect cleanup. useEffect(() => { const controller = new AbortController(); async function loadCustomer() { try { const response = await fetch( `/api/customers/${customerId}`, { signal: controller.signal } ); if (!response.ok) throw new Error("Request failed"); setCustomer(await response.json()); } catch (error) { if (error.name !== "AbortError") { setError(error); } } } loadCustomer(); return () => controller.abort(); }, [customerId]); An alternative is a request ID guard that ignores stale results. Test by deliberately resolving requests out of order and verifying only the newest customer is displayed.

If parsing or process() raises, file.close() might never execute. Use a context manager: import json def load_and_process(path): with open(path, encoding="utf-8") as file: payload = json.load(file) return process(payload) The file closes automatically when execution exits the with block, including on exceptions. It is closed before processing, which avoids holding the file open unnecessarily. Handle expected I/O and JSON decoding failures at the correct application boundary, and test malformed JSON as well as processing exceptions.

Use a transactional outbox. In one database transaction, insert the invoice and an outbox event with a stable event ID; commit both together. A separate worker claims pending events, sends the notification and marks the event delivered. If the database transaction fails, neither invoice nor event is saved. If delivery succeeds but the acknowledgement is lost, the event may be retried, so use a provider idempotency key or a durable sent-message ledger when possible. Add bounded retry/backoff and a dead-letter/error path. A plain retry loop does not guarantee exactly-once delivery, so repeated processing must be safe.

PUT is generally suitable when the target URI identifies a resource and the request replaces its representation. Repeating the same PUT should leave the intended resource state unchanged. POST commonly asks the server to process a request or create a subordinate resource and may produce duplicate effects if repeated. Idempotency describes the intended resulting state, not whether the server performs zero work on retries. For create/payment operations, accept an idempotency key, store its outcome and scope, and return the same outcome on a repeat. Define expiry and reject reuse of the same key with a different payload. Use a database constraint or transaction to make the idempotency record and business change consistent.

A linear-history rebase can be performed with: git fetch origin git switch feature git rebase origin/main Rebase replays commits and produces new commit IDs because the ancestry changes. That is usually manageable for a private branch. If others have based their work on the published commits, rewriting the branch can disrupt their history; coordinate first or merge main into the branch instead. If a published rebase must be pushed, use a carefully coordinated force-with-lease rather than an unconditional force push.

Construct the key from all inputs that affect the result, including resource ID and any required locale, tenant or authorization scope. Otherwise one request could receive another user's cached data. Set a bounded TTL based on freshness requirements, and evict/update after successful mutations. Consider request coalescing or a per-key async lock so simultaneous cache misses do not all run the same expensive query. Avoid caching sensitive per-user content under a shared key. In multi-node deployments, use shared storage or reliable invalidation events. Measure hit rate and test that changes become visible within the agreed consistency window.

Start with a baseline: latency percentiles, throughput, error rates and resource utilization. Correlate requests with trace/request IDs while excluding secrets and unnecessary personal data. Use distributed tracing to see time spent in the application, SQL, cache or external services. Check slow-query plans, locks and wait statistics. Compare slow requests by endpoint, payload size and time window. Reproduce in staging with representative anonymized data and a bounded load test. Change one likely bottleneck at a time and compare before/after measurements. Keep experiments reversible and do not overload production merely to reproduce the issue.

An empty successful result becomes indistinguishable from a database outage, timeout or programming bug. Downstream code may then make incorrect decisions while the incident is hidden. Let cancellation propagate when the caller cancels. Handle expected failures at a suitable boundary and log unexpected exceptions with a request/job ID without logging secrets. Example: try { return await repository.GetOrdersAsync(ct); } catch (OperationCanceledException) when (ct.IsCancellationRequested) { throw; } catch (SqlException ex) { logger.LogError(ex, "Failed to load orders for request {RequestId}", requestId); throw; } Exception middleware or the controller can return a safe 5xx response without exposing database details. Tests should confirm infrastructure failure is not represented as an empty successful result.

Push filtering, ordering and pagination into the database and project only required fields. var page = await db.Orders .AsNoTracking() .Where(o => o.CustomerId == customerId && o.CreatedAt >= start && o.CreatedAt < end) .OrderByDescending(o => o.CreatedAt) .ThenByDescending(o => o.Id) .Skip(offset) .Take(pageSize) .Select(o => new OrderSummaryDto { Id = o.Id, CreatedAt = o.CreatedAt, Total = o.Total }) .ToListAsync(cancellationToken); Enforce a maximum page size and stable ordering. An index that supports the filter and ordering may help, but choose it based on real query plans and workload. Avoid transferring unused columns and ensure parameter values are handled safely.

Version the schema change in an EF migration or reviewed, idempotent SQL script. Include data type, nullability, constraints, indexes and any required backfill. Test against both a clean disposable database and a representative existing schema. Review locking/runtime impact, backup and rollback/forward-fix plans, and record which schema version is deployed. For rolling deployments, keep the schema change backward-compatible with overlapping application versions where possible. Never assume a column exists just because it exists on one developer's machine; integration tests should validate schema setup before the feature is considered ready.

Parse worksheet cells by row and column; never split a question cell on its embedded newlines. Preserve the original row number for validation messages. Validate required cells, all four options, the answer key, duplicates within the uploaded workbook and duplicates already in the selected chapter, including archived rows if the policy requires it. Display the complete preview and block import when any row is invalid. On confirmation, re-check that the chapter is active and re-check duplicates because the database may have changed since preview. Save the entire batch in one database transaction so one failure cannot leave a partial import. Also enforce file size and row limits, validate the XLSX structure, require an authenticated administrator and test multiline cells, blank rows, invalid workbooks and duplicate races.