Review Checklist

When reviewing patches in Apache JIRA or GitHub pull requests, cover the following areas. This checklist is adapted from the project’s legacy development documentation.

Critical

  • Are all data inputs and outputs checked for the correct type, length, format, and range?

  • Where third-party utilities are used, are returned errors being caught?

  • Are invalid parameter values handled?

  • Are any Throwable or Exception instances passed to JVMStabilityInspector?

  • Do exceptions propagate to the appropriate level in the code?

  • Are errors well-documented, and do they tell the user how to proceed?

  • Do tests exist for the behavior, and do they cover the intended functionality?

  • Is the patch passing CI for all affected branches?

  • If the patch affects the read/write path, was it tested for performance regressions?

Important

  • Does it conform to the code style guidelines?

  • Is the code as modular as possible?

  • Can any singleton be avoided?

  • Can any of the code be replaced with library functions?

  • Are units of measurement used in the code consistent, both internally and with the rest of the ecosystem?

  • Do comments describe the intent of the code, not just the implementation?

  • Are Javadocs added where appropriate?

  • Is any unusual behavior or edge-case handling described?

  • Are data structures and units of measurement explained?

  • Is there any incomplete code that should be removed or flagged with TODO?

  • Does the code self-document via clear naming, abstractions, and flow control?

  • Have NEWS.txt, the CQL docs, and the native protocol spec been updated if needed?

  • Is the ticket tagged with client-impacting and doc-impacting where appropriate?

  • Has lib/licenses been updated for third-party libs, and are they Apache License compatible?

  • Is the Component on the JIRA ticket set appropriately?

  • Is the code testable, with no hidden dependencies that block reuse in tests?

  • Could test code use common functionality such as CCM, dtest, or CqlTester helpers?

  • If the code may be affected by multi-node clusters, are there dtests?

  • If the code may take a long time to test properly, are there continuous verification harness (CVH) tests?

  • If adding a new feature, were tests added for the expected SLA or use case?

Nice-to-have

  • Is there any redundant or duplicate code?

  • Are logging statements at the right level?

  • Are there logs in the critical path that could affect performance?

  • Is there any log that could be added to communicate status or troubleshoot potential problems?

  • Can any unnecessary logging statements be removed?