{"owner":"mongodb","repo":"mongo","hasSkills":true,"totalSkillsCount":12,"totalTokensCount":10449,"categories":["plugin-manifest","root-instruction","command-prompt","copilot-instructions","subagent-persona","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":["src/third_party/gperftools/README.md","jstests/AGENTS.md","buildscripts/resmokelib/extensions/README.md","src/mongo/db/commands/SCRIPTING_PROFILER_README.md",".github/copilot-instructions.md","src/mongo/tools/mongo_tidy_checks/README.md","src/mongo/tools/workload_simulation/throughput_probing/README.md","src/third_party/wiredtiger/.claude/agents/wt-build.md","src/mongo/db/commands/query_cmd/README.md","src/mongo/tools/workload_simulation/README.md","src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md",".cursorrules (nodejs-mongodb-cursorrules-prompt-file-tutorial.mdc)"],"skills":{"src/third_party/gperftools/README.md":"\n\nDon't make manual changes to files in the dist/ or platform/ directories.\nSource code changes should be made in the mongodb-labs/gperftools repo.\nTweaks or reconfigurations of our third-party installation have to be\nmade in scripts/ or BUILD.bazel files, etc.\n\n== contents ==\n\n```\n src/third_party/\n gperftool-2.7/\n dist/ # 'make distdir' snapshot of mongodb-labs/gperftools\n platform/\n linux_x86_64/ # per platform directories\n include/ # headers used by consumers of gperftools\n internal/ # headers used in the compile of gperftools\n ... # other platforms: $os_$arch\n windows_x86_64/ # special case that's always regenerated, and always the same way.\n scripts/\n import.sh # regenerate the dist/ snapshot from git repo.\n host_config.sh # generate platform headers dir for the host and windows_x86_64.\n```\n\n","jstests/AGENTS.md":"## JavaScript Test Code Conventions\n\n### Assertion Library\n\nALWAYS use our own assertion library that is defined at `src/mongo/shell/assert.js` and\nautomatically loaded into the global scope before running each test.\n\nALWAYS wrap commands with `assert.commandWorked()`, unless failures are expected and checked. Use\n`assert.writeOK()` when working with legacy bulk write APIs.\n\nUse `assert.soon()` only for asynchronous or eventually-consistent conditions.\n\n### Mocha Style for New Test Files\n\nUse the mocha style to structure test cases in newly added test files. The\n`jstests/libs/mochalite.js` module implements `describe`, `it`, `before`, `beforeEach`, `afterEach`,\nand `after`. Import only what you need. Feel free to add other mocha helper functions to\n`jstests/libs/mochalite.js` if they would make the current test cleaner.\n\n```js\nimport {before, describe, it} from \"jstests/libs/mochalite.js\";\n\ndescribe(\"feature under test\", function () {\n before(function () {\n /* one-time setup */\n });\n it(\"does X\", function () {\n /* ... */\n });\n});\n```\n\n### Use JSON-Conformant Object Serialization in Logs\n\nPass objects to the `attr` parameter of assertion and logging functions instead of concatenating\n`tojson()` into the message string. Most `assert.*` functions accept an `attr` object as their last\nargument.\n\n```js\n// Bad — tojson() in the message string\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing: \" + tojson(cursor));\n\n// Good — object passed via attr\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing\", {cursor});\n```\n\nFor logging:\n\n```js\n// Bad\njsTest.log.info(\"got cursor: \" + tojson(cursor));\n\n// Good\njsTest.log.info(\"got cursor\", {cursor});\n```\n\n### Resource and Settings Cleanup\n\nALWAYS clean up resources and settings immediately after they are no longer needed. Examples of\nserver resources are cursors and collections. Examples of settings are server parameters and test\nframework settings stored in the global `TestData` object.\n","buildscripts/resmokelib/extensions/README.md":"# Extensions\n\nThis module provides utilities for setting up and configuring MongoDB extensions in resmoke test\nsuites.\n\n## Overview\n\nExtensions are dynamically loaded shared objects (`.so` files) that provide additional functionality\nto MongoDB. The utilities in this folder can handle:\n\n1. Discovering extension `.so` files in build directories\n2. Generating `.conf` configuration files for extensions\n3. Cleaning up configuration files after tests\n\n## Configuration File Generation in Tests\n\nExtension `.conf` files are YAML configuration files that tell the server how to load an extension.\nThey contain:\n\n- `sharedLibraryPath`: Path to the `.so` file\n- `extensionOptions`: Optional configuration parameters for the extension\n\nFor example:\n\n```yaml\n# foo.conf\nsharedLibraryPath: /path/to/libfoo_mongo_extension.so\nextensionOptions:\n someSetting: \n```\n\n### How Config Files Are Generated\n\nThe `generate_extension_configs.py` module creates `.conf` files:\n\n1. Receives a list of `.so` file paths (either from automatic discovery via\n `find_and_generate_extension_configs.py`, or manually via `--so-files` command-line argument)\n2. For each `.so`, creates a `.conf` file in the temp directory (`/tmp/mongo/extensions/`)\n3. Looks up corresponding extension options from\n `src/mongo/db/extension/test_examples/configurations.yml`, if any are specified\n4. Writes the config file with `sharedLibraryPath` and any `extensionOptions`\n\n### Automatic Discovery and Generation\n\nThe `find_and_generate_extension_configs.py` module combines discovery and generation:\n\n1. Searches for `*_mongo_extension.so` files in build directories:\n - **Evergreen:** `dist-test/lib/`\n - **Local:** `bazel-bin/install-dist-test/lib/` or `bazel-bin/install-extensions/lib/`\n2. Generates `.conf` files with a unique UUID suffix to avoid collisions\n3. Adds the `loadExtensions` parameter to mongod/mongos options\n","src/mongo/db/commands/SCRIPTING_PROFILER_README.md":"# Scripting Profiler\n\n## Prerequisite\n\nThis is one time setup for a host.\n\n```bash\n# This cmd is for ubuntu20, different os may need different cmd. AWS (evergreen host) may require addition pkg.\nsudo apt install linux-tools-generic\n# Make sure `perf` command runs well, and /usr/bin/perf exists.\n```\n\nRun following commands to allow `perf` runs without root permission:\n\n```bash\nsudo sysctl -w kernel.perf_event_paranoid=1\nsudo sysctl -w kernel.kptr_restrict=0\n# This makes the change persistant across reboots\nsudo echo \"kernel.perf_event_paranoid=1\\nkernel.kptr_restrict=0\" > /etc/sysctl.d/perf.conf\n```\n\n## How to use\n\n### Start the profiler\n\nSyntax\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n filename: ,\n mode: \n }\n)\n```\n\nParameters\n\n- filename: The output file of linux-perf without suffix\n - type: `string`\n - default value: `perf`\n- mode: The profiling mode\n - type: `string`\n - possible values: `record` or `counters`\n - default value: `record`\n\nResponse\n\n```\n{ pid: , ok: 1 }\n```\n\n### Stop the profiler\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n pid: \n }\n)\n```\n\nParameters:\n\n- pid: This is the perf process pid, it is returned when profiler is started.\n - type: `integer`\n - required: `true`\n\n## Example\n\n```bash\n# Start the profiler.\nlet pid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_sbe\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler, and generate profiling data.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n# Change some settings (e.g. using classic engine).\ndb.adminCommand({setParameter: 1, internalQueryFrameworkControl: \"forceClassicEngine\"})\n# Start profiler again with a different file name.\npid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_classic\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n## Using Shell\nperf report -i /home/ubuntu/tmp/perf_sbe.data\nperf report -i /home/ubuntu/tmp/perf_classic.data\n# Or generate flame graph\n```\n",".github/copilot-instructions.md":"# Copilot instructions for this repository\n\n## Flag likely CVE / security-vulnerability fixes\n\nCommits on `master` are automatically synced to the public `mongodb/mongo` repository. A security\nfix that lands on `master` before the corresponding CVE is disclosed publicly reveals the\nvulnerability while released versions are still unpatched.\n\nWhen reviewing a pull request, flag it prominently if it looks like a fix for a security\nvulnerability or CVE. Signals include:\n\n- The PR, commit message, or linked ticket mentions a CVE, \"vulnerability\", \"security fix\",\n \"embargo\", or a security-team ticket.\n- The change fixes spoofing, forgery, injection, authentication/authorization bypass, privilege\n escalation, out-of-bounds access, or similar exploitable behavior.\n- The change hardens a trust boundary (e.g. validating previously trusted input from the network, a\n proxy header, or another node) or corrects audit-log attribution.\n- Documentation changes that describe how existing behavior can be abused by an attacker.\n\nIf any of these apply, add a review comment telling the author:\n\n> This PR looks like it may fix a security vulnerability. Because `master` is synced to the public\n> repository, this change must only be merged after the corresponding CVE has been publicly\n> disclosed and fixed releases are available. Confirm disclosure timing with the security team\n> before merging.\n\nDo not speculate about exploit details in review comments; just flag the disclosure-timing concern.\n","src/mongo/tools/mongo_tidy_checks/README.md":"# MongoDB Custom Clang Tidy module\n\nThe MongoDB server includes a custom clang-tidy module which allows server developers to write\ncustom clang-tidy rules for enforcement of best practices, finding bugs, and\n[large scale refactoring](https://www.youtube.com/watch?v=UfLH7dORav8). Checks for these rules will\nbe run as part of the commit queue and locally with the\n[clang-tidy vscode plugin](https://wiki.corp.mongodb.com/display/HGTC/Remote+Development+with+Visual+Studio+Code+%28vscode%29+for+MongoDB)\nor the clang-tidy command line.\n\nClang-tidy allows precise analysis of the code via the AST it builds internally. Our custom checks\nare employed through the use of a dynamic library which is loaded via the -load argument to\nclang-tidy. SDP and other teams plan to implement mongodb customized checks. If you are interested\nin implementing checks that can help enforce our standards in the codebase (or even just certain\ncomponents in the codebase), please reach out for more info.\n\nThe basics of implementing a check are in the\n[clang docs](https://releases.llvm.org/12.0.1/tools/clang/tools/extra/docs/clang-tidy/Contributing.html).\nIf you are planning to implement additional checks, it is highly recommended to look at the\n[existing clang tidy checks](https://github.com/llvm/llvm-project/tree/llvmorg-12.0.1/clang-tools-extra/clang-tidy)\nas reference starting material. Note that we use v4 toolchain with clang 12.0.1 and the clang tidy\ncheck API is subject to change between clang tidy versions. Also note that clang-tidy 12.0.1 release\ndoes not include the ability to load a module. This feature was backported into our v4 toolchain\nclang-tidy.\n\n#### Basic usage of the custom checks\n\nThe current directory contains the individual check source files, the main `MongoTidyModule.cpp`\nsource file which registers the checks, and the BUILD.bazel file responsible for building the check\nlibrary module. To build the custom checks use this command:\n\nThe bazel clang-tidy config will automatically build and use the custom checks module. To run clang\ntidy with the checks module use:\n\n bazel build --config=clang-tidy //src/mongo/...\n\n#### Adding check unittests\n\nA simple unittest framework is included with the checks so that they will automatically be run in\nquick, isolated, and minimal fashion. This allows for faster development and ensures the checks\ncontinue working.\n\nThe `test` directory contains the python unittest script, the test source files, and the BUILD.bazel\nwhich builds and runs the tests. To run all the custom tidy rules unittests use:\n\n bazel run mongo-tidy-test\n\nThis will run all the tests serially. Eventually we can improve this and they can be run in parallel\nbut currently they are serial. To run a specific test you can use python's unittest args, for\nexample:\n\nbazel run mongo-tidy-test -- -k test_MongoInvariantStatusIsOKCheck\n\n#### Writing your own check checklist\n\nBelow is a checklist of all the steps to make sure to perform when writing a new check.\n\n1. Implement the check in the respectively named `.h` and `.cpp` files.\n2. Add the check's `#include` to the `MongoTidyModule.cpp`.\n3. Register the check class with a check name in the `MongoTidyModule.cpp`.\n4. Add the `.cpp` file to the source list in the `BUILD.bazel` file.\n5. Write a unittest file named `tests/test_{CHECK_NAME}.cpp` and a config file\n `tests/test_{CHECK_NAME}.tidy_config` which minimally reproduces the issue.\n6. Add the test to the list of tests in `tests/BUILD.bazel`.\n7. Add a `def test_{CHECK_NAME}():` function to the `MongoTidyCheck_unittest.py` file which finds\n the expected error output in the stdout. Reference the other check functions for details.\n8. Run the bazel build with `bazel run mongo-tidy-test -- -k test_{CHECK_NAME}` to run the newly\n created test.\n\n#### Questions and Troubleshooting\n\nIf you have any questions please reach out to the `#ask-devprod-build` slack channel.\n","src/mongo/tools/workload_simulation/throughput_probing/README.md":"# Throughput Probing Simulations\n\nThis directory provides code for an executable `throughput_probing_simulator` that tests our\nthroughput probing algorithm used for execution control under a simulated workload. The workload\noutput consists of graphs showing the actual and optimal ticket allocations over time.\n\nThe rough workflow for an individual simulation is:\n\n1. Specify an optimal concurrency level, and the throughput at that concurrency level.\n2. Provide a well-behaved model for what throughput we will observe at different concurrency levels,\n and what operation latencies would produce that throughput.\n3. Use that model to specify a workload driver which simulates operations with the given latencies\n based on the current concurrency level selected by the throughput probing algorithm.\n4. Run the mock workload for specified duration.\n\n## File Structure\n\nNew workloads can be added in [`workloads.cpp`](workloads.cpp)\n\nThe existing `TicketedWorkloadDriver` is quite flexible, and should suffice for most workloads by\nsimply tuning the workload characteristics, runtime, etc. New workload characterstic types can be\ndefined in [`workload_characteristics.h`](../workload_characteristics.h).\n","src/third_party/wiredtiger/.claude/agents/wt-build.md":"---\nname: wt-build\ndescription: Use this agent when WiredTiger C/C++ source or test code has changed and the CMake build needs verification. Typical triggers include verifying a fresh edit compiles before running tests, a pre-commit sanity check after touching files under `src/` or `test/` (Catch2, csuite, cppsuite, format, etc.), and confirming a newly added source or test file is wired into the build.\ntools: [\"Bash\", \"Read\", \"Glob\", \"Grep\"]\nmodel: haiku\ncolor: yellow\n---\n\nYou are a build runner for WiredTiger. Compile the code with CMake and report the result. Be terse.\n\n## Procedure\n\n1. **Configure if needed.** If `build/CMakeCache.txt` exists, skip — respect the caller's existing configuration. Otherwise:\n ```\n cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug\n ```\n Default to `-DCMAKE_BUILD_TYPE=Debug` unless the caller specifies a different build type. Drop `-G Ninja` if `ninja` is not installed. Do not add other `-D` flags unless the caller asks; team members configure their own builds.\n\n2. **Pick a target.** If the caller named a CMake target, use it. Otherwise build everything.\n\n3. **Build**, redirecting output to a log file. The unfiltered output is large — never let it stream into your context:\n ```\n cmake --build build --parallel --target > build/last-build.log 2>&1\n ```\n Omit `--target ` for the fallback case. Report which target you built (or `all`) in the success/failure output so the caller can verify the scope.\n\n4. **Report.** On success, emit `SUCCESS` plus the target built and the last line of the log. On failure, emit `FAILED` plus the target and `file:line` for each error pulled from `build/last-build.log`. Use a grep that covers both GNU and macOS linker output:\n ```\n grep -E \"error:|undefined reference|Undefined symbols|ld: symbol|No such file|fatal error\" build/last-build.log | head -20\n ```\n\n## Edge cases\n\n- **Stale build directory.** If configure succeeds but the build fails with errors that look like missing files the caller just deleted (e.g. `No such file or directory` on a removed source), suggest the caller re-run `cmake -B build -G Ninja` or wipe `build/` — do not delete it yourself.\n- **Interrupted build.** If `cmake --build` exits non-zero with no errors in the log (e.g. SIGINT), report `FAILED — build interrupted, no errors logged` rather than inventing errors.\n- **Configure failure.** If the initial `cmake -B build` fails, report `FAILED` with the cmake error and stop; do not attempt to build.\n\n## Output format\n\n**On success:**\n```\nSUCCESS (target: ) — \n```\n\n**On failure:**\n```\nFAILED (target: )\n\nErrors:\n src/foo.c:123: error: 'bar' undeclared\n src/baz.c:45: error: ...\n\nLog: build/last-build.log\n```\n","src/mongo/db/commands/query_cmd/README.md":"# Parsing\n\n## Overview\n\nThe query system's parsing layer has two main components:\n\n1. [Command Parsing and Validation](#command-parsing-and-validation) is responsible for parsing the\n arguments to each command, verifying the expected number of arguments, and checking their types.\n1. [Query Language Parsing and Validation](#query-language-parsing-and-validation) is responsible\n for more query-specific parsing. This includes (but is not limited to) parsing query predicates\n and aggregation pipelines.\n\nOverall, the parsing layer translates from a client-facing command (e.g. find or aggregate) to a\nparsed command object (e.g. `ParsedFindCommand` or `Pipeline`). These parsed command objects are\nthen normalized to form the input of query planning: `CanonicalQuery`,\n[if possible](#parsing-aggregations).\n\n> ### Aside: `CanonicalQuery`\n>\n> A\n> [`CanonicalQuery`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/query/canonical_query.h#L72)\n> is a container that represents a parsed and normalized query. This includes features such as the\n> query's `filter`, `projection`, and `sort` elements. See\n> [here](../../query/README_logical_models.md#canonicalquery) for more information regarding\n> `CanonicalQuery` and its normalization.\n\n## Command Parsing and Validation\n\nThe QO team maintains the following commands:\n\n- Category 1: Basic Read Queries\n - `find`\n - `distinct`\n - `count`\n- Category 2: Aggregations\n - `aggregate`\n - `mapReduce`\n - Note: `mapReduce` was deprecated in MongoDB v5.0 in favor of standard aggregation.\n- Category 3: Write Queries\n - `insert`\n - `delete`\n - `update`\n - `findAndModify`\n\nEach command starts in a class that inherits from the\n[`Command`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/commands.h#L436)\nabstract class. These commands all live in the [`src/mongo/db/commands/`](/src/mongo/db/commands)\ndirectory. For example:\n\n- `FindCmd` lives in [find_cmd.cpp](/src/mongo/db/commands/query_cmd/find_cmd.cpp)\n- `aggregate`'s command (`AggregateCommand`) lives in\n [`aggregate_command.cpp`](/src/mongo/db/commands/query_cmd/aggregate_command.cpp).\n\nFirst, we piece apart the command into its components. We don't yet try to understand the meaning of\nthe more complex MQL arguments, such as find's `filter`, `projection`, and `sort` arguments, or the\nindividual stages in `aggregate`'s `pipeline` argument.\n\n> ### Aside: Command Parsing vs. Query Parsing\n>\n> The overall parsing layer reflects this hierarchy:\n>\n> 1. A valid bytestring may contain a possibly valid `BSON`, extracted using a **BSON parser**.\n> 1. A valid `BSON` may contain a possibly valid **command**, extracted using a\n> [**command parser**](#aside-the-interface-definition-language).\n> 1. A valid command may contain a possibly valid **query**, extracted using an\n> [**MQL parser**](#query-language-parsing-and-validation).\n>\n> At this point, we are considering the second layer, from `BSON` to `Command`.\n\nFor example, given this find query:\n\n```\ndb.c.find({$or: [{a: {$lt: 2}}, {a: 6}]}).sort({a: 1}).limit(5);\n```\n\nwe generate a C++ struct that stores `filter`, `sort`, and `limit` as member variables. Note that\n`filter` is left as a `BSONObj`; we don't yet \"know\" that it contains a `$or`. Rather than manually\nwriting the conversion code, we use an **Interface Definition Language** (IDL) tool to generate the\nparser and output a corresponding C++ struct. In the `find` case, `find_command.idl` generates\n`find_command_gen.h` and `find_command_gen.cpp` and by extension, a `FindCommandRequestBase` struct.\n\n> ### Aside: The Interface Definition Language\n>\n> Below is a simplified snippet of the relevant portion of `find_command.idl`. The full file can be\n> viewed [here](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/find_command.idl).\n>\n> ```yaml\n> commands:\n> find:\n> cpp_name: FindCommandRequestBase\n> command_name: find\n> description: \"A struct representing the find command\"\n> fields:\n> filter:\n> description: \"The query predicate. If unspecified, then all documents in the collection\n> will match the predicate.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> sort:\n> description: \"The sort specification for the ordering of the results.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> limit:\n> description: \"The maximum number of documents to return.\"\n> type: safeInt64\n> optional: true\n> validator: { gte: 0 }\n> stability: stable\n> ```\n>\n> This file (specified in a YAML format) is used to generate C++ code that will in turn create a\n> `FindCommandRequestBase`. Our build system will run a python tool to parse this YAML and spit out\n> C++ code which is then compiled and linked. This code is left in a file ending with '\\_gen.h' or\n> '\\_gen.cpp' (here `find_command_gen.cpp`). The YAML includes specifications of each field, such as\n> its type, whether it is optional, and any default values. The generated file will have getter and\n> setter member functions and will return a `boost::optional` for optional fields. Now, we have a\n> `FindCommandRequestBase` struct that neatly contains C++ members for each of the components of our\n> query.\n\n### Additional Setup Before MQL Processing\n\n#### `ExpressionContext`\n\nAn\n[**`ExpressionContext`**](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/pipeline/expression_context.h#L132)\nstores various pieces of state and settings that are pertinent throughout the lifespan of a query\nbut are not necessarily relevant to other types of operations. This includes elements such as the\ncollation, a time zone database, and other configuration flags (feature flags, query knobs, etc.).\nEach command initializes its own `ExpressionContext`; our `find` example does so\n[here](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L191).\n\n#### Non-IDL Command Validation\n\nOccasionally, the IDL parsers will not be able to express certain command constraints. For example,\nthe `findAndModify` command cannot specify `true` for both `remove` and `new`, but the\n[IDL parser](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/write_ops/write_ops.idl#L533)\nalone cannot restrict the user from doing this. In these cases, we add a\n[`validate()`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_and_modify.cpp#L133)\nfunction to perform these final checks.\n\n## Query Language Parsing and Validation\n\n### Parsing Read Queries: Find, Distinct, and Count\n\n#### Parsing Find\n\nAs discussed above, the IDL handles creation of a `FindCommandRequest`. With this\n`FindCommandRequest` struct, we can now call\n[`parsed_find_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196),\npassing in the `ExpressionContext` and a new struct of type `ParsedFindCommandParams`, which\ncontains the `FindCommandRequest` as a member. A few function calls later, we reach\n[`MatchExpressionParser::parse()`](https://github.com/mongodb/mongo/blob/0a68308f0d39a928ed551f285ba72ca560c38576/src/mongo/db/query/parsed_find_command.cpp#L186)\nwhich recursively parses the `BSONObj` `filter` component of our `FindCommandRequest` by using the\n`parse()` function for each type of `MatchExpression` node. This AST structure assembles the\n`filter` in an easily optimizable format, as each subclass `MatchExpression` node knows which\nrewrites are possible given their place in the AST. For more information on `MatchExpression`s, see\n[Logical Models](../../query/README_logical_models.md).\n\nAfter parsing our `MatchExpression` into a tree of `MatchExpression`s , we pass the full\n`MatchExpression` AST to a `ParsedFindCommand`. Note that `ParsedFindCommand`s only primary\ncomponents are the `filter`, `projection`, and `sort`; all other parameters (e.g. `limit`, `skip`,\n`batchSize`, etc.) are held as raw types in the `FindCommandRequest`.\n\nFinally, we\n[create](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196)\na `CanonicalQuery` by passing the `ParsedFindCommand` as an argument, thereby giving the\n`CanonicalQuery` the `filter`, `projection`, `sort`, and `FindCommandRequest`.\n\n#### Parsing Distinct and Count\n\nThe process of parsing `distinct` and `count` queries is nearly identical to that of `find`.\n\nDistinct queries are parsed by IDL into a `DistinctCommandRequest`, which is in turn converted into\na `ParsedDistinctCommand` by\n[`parsed_distinct_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_distinct_command.cpp#L132).\nIf a `filter` exists on the command, it is parsed using `MatchExpressionParser::parse()` like\n`find`. We then create a `CanonicalQuery` by an equivalent process to find, and\n[add a `CanonicalDistinct`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/parsed_distinct_command.cpp#L277)\nproperty to the `CanonicalQuery` with the details of the `distinct` query, such as its distinct key.\n\nCount queries are parsed using `ParsedFindCommand`'s\n[`parseFromCount()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_find_command.cpp#L346)\nfunction, which converts a `CountCommandRequest` into a `FindCommandRequest` and uses the same logic\nas `find` thereafter.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s1[\" \"]\n n1[\"Find\"]\n n2[\"Distinct\"]\n n3[\"Count\"]\n end\n n1 --> n10[\"IDL Parsing\"]\n n2 --> n10\n n3 --> n10\n n10 --> n11[\"FindCommandRequest\"] & n12[\"DistinctCommandRequest\"]\n n10 --> n21[\"CountCommandRequest\"]\n n13[\"ParsedFindCommand\"] --> n17[\"CanonicalQuery\"]\n n19[\"ParsedDistinctCommand\"] --> n17\n n21 -- parseFromCount() --> n11\n n11 -- \"parsed_find_command::parse()
MatchExpressionParser::parse()\" --> n13\n n12 -- \"parsed_distinct_command::parse()
MatchExpressionParser::parse()\" --> n19\n\n n10@{ shape: extract}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Aggregations\n\nAfter producing an `AggregateCommandRequest` via IDL, the request is\n[passed and parsed](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_pipeline.h#L70)\ninto a `LiteParsedPipeline`.\n\n> ### Aside: `LiteParsedPipeline`\n>\n> A `LiteParsedPipeline` is a simple model of an aggregation pipeline that is constructed through a\n> [semi-parse](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_document_source.h#L145)\n> that proceeds just enough to tease apart the stages that are involved. `LiteParsedPipeline`s do\n> not verify that the input is well-formed; instead, they can be used to _inspect_ queries before\n> building a full model of the user's pipeline.\n>\n> - For example, on systems running with authorization, the `$currentOp` aggregation stage requires\n> that the user has access that includes the\n> [`inprog`](https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-inprog)\n> privilege action. That means that if our `LiteParsedPipeline` finds a `$currentOp` that does not\n> satisfy the\n> [necessary privileges](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_current_op.h#L105),\n> we can\n> [return an error](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/auth/authorization_checks.cpp#L90)\n> and avoid the more expensive `DocumentSource` parsing process.\n\nAfter confirming that the `LiteParsedPipeline` satisfies all the necessary permissions, the full\n`AggregateCommandRequest` is passed to\n[`Pipeline::parseCommon()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L213)\nas a vector of pipeline stages (represented as raw `BSONObj`s). Each pipeline stage is then\nre-parsed using\n[`DocumentSource::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.cpp#L101),\nwhich calls on the `DocumentSource::createFromBson()` parser for each stage. At the time of\nthis writing, this double parse happens for all stages, but\n[SPM-4362](https://jira.mongodb.org/browse/SPM-4362) is aiming to make it possible to 'upgrade' a\n`LiteParsedPipeline` to a full `Pipeline` without re-parsing from raw BSON. We will prototype this\ncapability but not replace all existing stage's parsing implementations. This will be important for\nextensions processing though - it's a step towards a world where full parsing and query shape\ngeneration happen earlier in the process.\n\n> ### Aside: `DocumentSource`\n>\n> A `DocumentSource` represents one stage of an aggregation pipeline. Each `DocumentSource` lives in\n> its own file with this form:\n> [`src/mongo/db/pipeline/document_source_`](https://github.com/mongodb/mongo/tree/master/src/mongo/db/pipeline),\n> with a\n> [`REGISTER_DOCUMENT_SOURCE`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.h#L99)\n> macro at the top. Each `DocumentSource` also features a `createFromBson()` function; this is the\n> main parsing function for each `DocumentSource`. By registering each document source with its lite\n> parsing and full parsing functions, we can recursively parse the entire pipeline, stage by stage.\n>\n> Not all `DocumentSource`s get parsed into their own stages. Major stages like `$match` do have a\n> [`createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_match.cpp#L594)\n> that returns a `DocumentSourceMatch`, but some stages are aliases for other `DocumentSource`s.\n>\n> - For example,\n> [`DocumentSourceBucket::createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_bucket.cpp#L74)\n> returns two `DocumentSource`s: a `$group` stage and a `$sort` stage by calling on\n> `DocumentSourceGroup` and `DocumentSourceSort`'s respective `createFromBson()` functions.\n\nThe\n[result](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L233)\nof this parsing is a\n[`Pipeline`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.h#L110)\nobject that contains a list of parsed `DocumentSource`s as a member. Our final goal, however, is to\nget a `CanonicalQuery`. This may or may not be possible depending on the type of aggregation. For\nexample:\n\n> ```\n> // This query fully undergoes optimization as a CanonicalQuery.\n> db.c.aggregate([{$match: {a: {$gte: 2, $lte: 10}}}, {$sort: {a: 1}}, {$limit: 5}])\n> // This query is not canonicalizable.\n> db.c.aggregate([{$addFields: {b: {$add: [\"$a\", 1]}}}])\n> ```\n\nIf some component of the `Pipeline` can become a `CanonicalQuery` (i.e. it contains a filter, sort,\nprojection, etc.), we will\n[create a `CanonicalQuery`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline_d.cpp#L1144)\nfor this `Pipeline`, and proceed with optimization and execution as we would with a find command.\n\n#### Parsing MapReduce\n\nAfter parsing into a `MapReduceCommandRequest` via IDL, the `MapReduceCommandRequest` is\n[translated](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/map_reduce_agg.cpp#L187)\ninto an equivalent pipeline using the same `DocumentSource` parsing functions as aggregation.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s2[\" \"]\n n4[\"Aggregate\"]\n n5[\"MapReduce\"]\n end\n n4 --> n21[\"IDL Parsing\"]\n n5 --> n21\n n21 --> n22[\"AggregateCommandRequest\"] & n30[\"MapReduceCommandRequest\"]\n n22 --> n23[\"LiteParsedPipeline\"]\n n23 -- Authorization Checks --> n22\n n28[\"Pipeline\"] --> n32[\"Is some component of the Pipeline canonicalizable?\"]\n n32 -- No --> n33>\"DocumentSourceExecution\"]\n n22 -- Pipeline::parseCommon()
DocumentSource::parse() --> n31[\"DocumentSources\"]\n n30 --> n31\n n31 -- \"DocumentSource<Stage>::createFromBson()\" --> n28\n n32 -- \"Yes
createCanonicalQuery()\" --> n17[\"CanonicalQuery\"]\n\n n21@{ shape: extract}\n n32@{ shape: diam}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Write Queries\n\nInsert, Delete, Update, and FindAndModify are all parsed by IDL as described above and converted\ninto a `BulkWriteCommandRequest`, `DeleteRequest`, `UpdateRequest`, `FindAndModifyCommandRequest`,\nrespectively.\n\nInserts are internally\n[represented](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/bulk_write.idl#L324)\nas a `BulkWriteCommandRequest` which contains an array of `BulkWriteInsertOp`s. No query\noptimization is needed for inserts beyond parsing, since insert is a write-only operation.\n\n`DeleteRequest`s are passed to `parsed_delete_command::parse()`, which parses them into\n`ParsedDelete` objects. `parsed_delete_command::parse()` uses `parseWriteQueryToParsedFindCommand()`\nto parse the `filter` component of the write query. This shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedDelete`. Subsequently, the `ParsedDelete` objects are passed to `CanonicalDelete::make()`,\nwhich constructs a `CanonicalDelete` consisting of a `CanonicalQuery`.\n\n`UpdateRequest`s are passed to `parsed_update_command::parse()`, which parses them into\n`ParsedUpdate` objects. `parsed_update_command::parse()` uses\n`parseWriteQueryToParsedFindCommand()`, which shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedUpdate`. Subsequently, the `ParsedUpdate` objects are passed to `CanonicalUpdate::make()`,\nwhich constructs a `CanonicalUpdate` consisting of a `CanonicalQuery`.\n\n`FindAndModifyCommandRequest`s can contain both find and update/delete syntax. For this reason, the\nquery portion is entirely delegated to the `find` query parser. The update or delete portion is\ntranslated into a `CanonicalUpdate` or `CanonicalDelete`, each of which uses the corresponding\ncodepath henceforth.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s3[\" \"]\n n6[\"Insert\"]\n n7[\"Delete\"]\n n8[\"Update\"]\n n9[\"FindAndModify\"]\n end\n n6 --> n31[\"IDL Parsing\"]\n n7 --> n31\n n8 --> n31\n n9 --> n31\n n31 --> n32[\"BulkWriteCommandRequest\"] & n34[\"DeleteRequest\"] & n35[\"UpdateRequest\"] & n39[\"FindAndModifyCommandRequest\"]\n n32 --o n33[\"BulkWriteInsertOp\"]\n n34 -- \"parsed_delete_command::parse()\" --> n36[\"ParsedDelete\"]\n n35 -- \"parsed_update_command::parse()\" --> n37[\"ParsedUpdate\"]\n n39 --> n36\n n39 --> n37\n n36 -- \"CanonicalDelete::make()\" --> n40[\"CanonicalDelete\"]\n n37 -- \"CanonicalUpdate::make()\" --> n41[\"CanonicalUpdate\"]\n n40 --o n17[\"CanonicalQuery\"]\n n41 --o n17\n\n n17@{ shape: dbl-circ}\n n31@{ shape: extract}\n```\n\n---\n\n[Return to Cover Page](../../query/README_QO.md)\n","src/mongo/tools/workload_simulation/README.md":"# Workload Simulation\n\nThis directory provides code for generating `*_simulator` executables that test various components\nof the system under a simulated workload. The executables produces log output that can be converted\ninto graphs plotting metrics collected over time using `process_logs.py`.\n\nThe simulations themselves are carried out using an event queue and a mock clock. Workload drivers\nspawn and manage actor threads that are responsible for sending _event_ requests to the queue, where\neach request is tied to a time. The queue is responsible for advancing the clock appropriately and\nnotifying the actor threads when the clock has reached the appropriate time for their requests to be\nprocessed. Additional, non-actor threads can similarly wait for specific times during the simulation\nby registering _observer_ requests that are maintained in a separate internal queue.\n\nMore specifically:\n\n1. The event queue waits until it has received an _event_ request from each reported actor thread.\n2. When it is sufficiently full, the queue determines the minimum time of a queued _event_ request,\n and advances the mock clock to that time.\n3. The queue then notifies any threads waiting on either _event_ or _observer_ requests at or before\n the current time.\n\nThe _observer_ mechanism is used to trigger periodic metric reporting for the log output. It may\nalso be used by workload drivers to trigger periodic jobs.\n\n## Defining a Simulation\n\nThe [`simulation.h`](simulation.h) header defines a `SIMULATION` macro that functions similarly to\nthe `TEST_F` macro in our unittesting framework. It expects the first parameter to be the name of a\nfixture class derived from `mongo::workload_simulation::Simulation`. The second parameter is the\nname of the workload, and any additional parameters will be passed as input to the constructor of\nthe fixture class.\n\nA C++ file that defines these macros can be compiled using the `simulator_main` bazel target to link\nthe relevant `main` implementation that runs all the workloads defined using the macro.\n\n## Generating Visualizations\n\nA `*_simulator` executable simply runs all selected workloads and outputs logs to stdout. These logs\ncan be piped to `process_logs.py` to generate graphs. Ex.\n\n```\n$ throughput_probing_simulator | process_logs.py -o ~/sim_output\n```\n","src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md":"# rootAnalysis Documentation\n\nPath: `src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md)",".cursorrules (nodejs-mongodb-cursorrules-prompt-file-tutorial.mdc)":"---\ndescription: \"Cursor rules for Node.js development with MongoDB integration.\"\nglobs: **/*\nalwaysApply: false\n---\nTech Stack:\n\nBackend: Node.js with Express.js\n\nDatabase: MongoDB with Mongoose ODM\n\nFrontend: React.js (for admin panel, if required)\n\nAuthentication: JSON Web Tokens (JWT)\n\nVersion Control: Git\n\nDeployment: Docker (optional)\n\nPrecision in User Requirements:\n\nStrictly adhere to specified user flow and game rules.\n\nStrategy: \n\nSummarize the pick submission process and outline the API endpoint and business logic in pseudocode before coding.\n\nStrategic Planning with Pseudocode:\n\nBegin each feature with detailed pseudocode.\n\nExample: Provide pseudocode for the weekly scoring process, detailing steps from game result input to entry status updates.\n\nCode Quality:\n\nEnsure secure, efficient code following RESTful API best practices.\n\nImplement proper error handling and input validation.\n\nUser Flow:\n\nUsers browse available Pools\n\nSubmit up to 3 Requests per Pool\n\nComplete payment for Requests\n\nAdmin approves/rejects Requests\n\nApproved Requests become Entries\n\nEntry Management:\n\nEach user can have up to 3 Entries per Pool\n\nEntries are numbered 1, 2, 3\n\nPicks are made and tracked separately for each Entry\n\nPick Management:\n\nUsers make Picks for each Entry separately\n\nPicks can be updated until deadline (game start or 1PM Sunday of the current week of the pick)\n\nScoring and Ranking:\n\nPicks scored after games complete\n\nWin: Entry moves to next week\n\nLoss: Entry eliminated from Pool\n\nEach Entry ranked separately in Pool standings\n\nResults and Standings:\n\nUsers view Picks/scores for each Entry separately\n\nPool standings show all Entries (multiple per User possible)\n\nPool members can view all Picks after scoring\n\nKey Implementation Points:\n\nLimit Requests to 3 per User per Pool\n\nTrack Requests and Entries separately (numbered 1, 2, 3)\n\nImplement payment status tracking in Request model\n\nCreate Entry only after admin approval and payment completion\n\nAdmin interface for managing and approving Requests\n\nImplement state transitions (Request: pending -> approved -> Entry created)\n"},"files":{"src/third_party/gperftools/README.md":"\n\nDon't make manual changes to files in the dist/ or platform/ directories.\nSource code changes should be made in the mongodb-labs/gperftools repo.\nTweaks or reconfigurations of our third-party installation have to be\nmade in scripts/ or BUILD.bazel files, etc.\n\n== contents ==\n\n```\n src/third_party/\n gperftool-2.7/\n dist/ # 'make distdir' snapshot of mongodb-labs/gperftools\n platform/\n linux_x86_64/ # per platform directories\n include/ # headers used by consumers of gperftools\n internal/ # headers used in the compile of gperftools\n ... # other platforms: $os_$arch\n windows_x86_64/ # special case that's always regenerated, and always the same way.\n scripts/\n import.sh # regenerate the dist/ snapshot from git repo.\n host_config.sh # generate platform headers dir for the host and windows_x86_64.\n```\n\n","jstests/AGENTS.md":"## JavaScript Test Code Conventions\n\n### Assertion Library\n\nALWAYS use our own assertion library that is defined at `src/mongo/shell/assert.js` and\nautomatically loaded into the global scope before running each test.\n\nALWAYS wrap commands with `assert.commandWorked()`, unless failures are expected and checked. Use\n`assert.writeOK()` when working with legacy bulk write APIs.\n\nUse `assert.soon()` only for asynchronous or eventually-consistent conditions.\n\n### Mocha Style for New Test Files\n\nUse the mocha style to structure test cases in newly added test files. The\n`jstests/libs/mochalite.js` module implements `describe`, `it`, `before`, `beforeEach`, `afterEach`,\nand `after`. Import only what you need. Feel free to add other mocha helper functions to\n`jstests/libs/mochalite.js` if they would make the current test cleaner.\n\n```js\nimport {before, describe, it} from \"jstests/libs/mochalite.js\";\n\ndescribe(\"feature under test\", function () {\n before(function () {\n /* one-time setup */\n });\n it(\"does X\", function () {\n /* ... */\n });\n});\n```\n\n### Use JSON-Conformant Object Serialization in Logs\n\nPass objects to the `attr` parameter of assertion and logging functions instead of concatenating\n`tojson()` into the message string. Most `assert.*` functions accept an `attr` object as their last\nargument.\n\n```js\n// Bad — tojson() in the message string\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing: \" + tojson(cursor));\n\n// Good — object passed via attr\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing\", {cursor});\n```\n\nFor logging:\n\n```js\n// Bad\njsTest.log.info(\"got cursor: \" + tojson(cursor));\n\n// Good\njsTest.log.info(\"got cursor\", {cursor});\n```\n\n### Resource and Settings Cleanup\n\nALWAYS clean up resources and settings immediately after they are no longer needed. Examples of\nserver resources are cursors and collections. Examples of settings are server parameters and test\nframework settings stored in the global `TestData` object.\n","buildscripts/resmokelib/extensions/README.md":"# Extensions\n\nThis module provides utilities for setting up and configuring MongoDB extensions in resmoke test\nsuites.\n\n## Overview\n\nExtensions are dynamically loaded shared objects (`.so` files) that provide additional functionality\nto MongoDB. The utilities in this folder can handle:\n\n1. Discovering extension `.so` files in build directories\n2. Generating `.conf` configuration files for extensions\n3. Cleaning up configuration files after tests\n\n## Configuration File Generation in Tests\n\nExtension `.conf` files are YAML configuration files that tell the server how to load an extension.\nThey contain:\n\n- `sharedLibraryPath`: Path to the `.so` file\n- `extensionOptions`: Optional configuration parameters for the extension\n\nFor example:\n\n```yaml\n# foo.conf\nsharedLibraryPath: /path/to/libfoo_mongo_extension.so\nextensionOptions:\n someSetting: \n```\n\n### How Config Files Are Generated\n\nThe `generate_extension_configs.py` module creates `.conf` files:\n\n1. Receives a list of `.so` file paths (either from automatic discovery via\n `find_and_generate_extension_configs.py`, or manually via `--so-files` command-line argument)\n2. For each `.so`, creates a `.conf` file in the temp directory (`/tmp/mongo/extensions/`)\n3. Looks up corresponding extension options from\n `src/mongo/db/extension/test_examples/configurations.yml`, if any are specified\n4. Writes the config file with `sharedLibraryPath` and any `extensionOptions`\n\n### Automatic Discovery and Generation\n\nThe `find_and_generate_extension_configs.py` module combines discovery and generation:\n\n1. Searches for `*_mongo_extension.so` files in build directories:\n - **Evergreen:** `dist-test/lib/`\n - **Local:** `bazel-bin/install-dist-test/lib/` or `bazel-bin/install-extensions/lib/`\n2. Generates `.conf` files with a unique UUID suffix to avoid collisions\n3. Adds the `loadExtensions` parameter to mongod/mongos options\n","src/mongo/db/commands/SCRIPTING_PROFILER_README.md":"# Scripting Profiler\n\n## Prerequisite\n\nThis is one time setup for a host.\n\n```bash\n# This cmd is for ubuntu20, different os may need different cmd. AWS (evergreen host) may require addition pkg.\nsudo apt install linux-tools-generic\n# Make sure `perf` command runs well, and /usr/bin/perf exists.\n```\n\nRun following commands to allow `perf` runs without root permission:\n\n```bash\nsudo sysctl -w kernel.perf_event_paranoid=1\nsudo sysctl -w kernel.kptr_restrict=0\n# This makes the change persistant across reboots\nsudo echo \"kernel.perf_event_paranoid=1\\nkernel.kptr_restrict=0\" > /etc/sysctl.d/perf.conf\n```\n\n## How to use\n\n### Start the profiler\n\nSyntax\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n filename: ,\n mode: \n }\n)\n```\n\nParameters\n\n- filename: The output file of linux-perf without suffix\n - type: `string`\n - default value: `perf`\n- mode: The profiling mode\n - type: `string`\n - possible values: `record` or `counters`\n - default value: `record`\n\nResponse\n\n```\n{ pid: , ok: 1 }\n```\n\n### Stop the profiler\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n pid: \n }\n)\n```\n\nParameters:\n\n- pid: This is the perf process pid, it is returned when profiler is started.\n - type: `integer`\n - required: `true`\n\n## Example\n\n```bash\n# Start the profiler.\nlet pid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_sbe\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler, and generate profiling data.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n# Change some settings (e.g. using classic engine).\ndb.adminCommand({setParameter: 1, internalQueryFrameworkControl: \"forceClassicEngine\"})\n# Start profiler again with a different file name.\npid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_classic\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n## Using Shell\nperf report -i /home/ubuntu/tmp/perf_sbe.data\nperf report -i /home/ubuntu/tmp/perf_classic.data\n# Or generate flame graph\n```\n",".github/copilot-instructions.md":"# Copilot instructions for this repository\n\n## Flag likely CVE / security-vulnerability fixes\n\nCommits on `master` are automatically synced to the public `mongodb/mongo` repository. A security\nfix that lands on `master` before the corresponding CVE is disclosed publicly reveals the\nvulnerability while released versions are still unpatched.\n\nWhen reviewing a pull request, flag it prominently if it looks like a fix for a security\nvulnerability or CVE. Signals include:\n\n- The PR, commit message, or linked ticket mentions a CVE, \"vulnerability\", \"security fix\",\n \"embargo\", or a security-team ticket.\n- The change fixes spoofing, forgery, injection, authentication/authorization bypass, privilege\n escalation, out-of-bounds access, or similar exploitable behavior.\n- The change hardens a trust boundary (e.g. validating previously trusted input from the network, a\n proxy header, or another node) or corrects audit-log attribution.\n- Documentation changes that describe how existing behavior can be abused by an attacker.\n\nIf any of these apply, add a review comment telling the author:\n\n> This PR looks like it may fix a security vulnerability. Because `master` is synced to the public\n> repository, this change must only be merged after the corresponding CVE has been publicly\n> disclosed and fixed releases are available. Confirm disclosure timing with the security team\n> before merging.\n\nDo not speculate about exploit details in review comments; just flag the disclosure-timing concern.\n","src/mongo/tools/mongo_tidy_checks/README.md":"# MongoDB Custom Clang Tidy module\n\nThe MongoDB server includes a custom clang-tidy module which allows server developers to write\ncustom clang-tidy rules for enforcement of best practices, finding bugs, and\n[large scale refactoring](https://www.youtube.com/watch?v=UfLH7dORav8). Checks for these rules will\nbe run as part of the commit queue and locally with the\n[clang-tidy vscode plugin](https://wiki.corp.mongodb.com/display/HGTC/Remote+Development+with+Visual+Studio+Code+%28vscode%29+for+MongoDB)\nor the clang-tidy command line.\n\nClang-tidy allows precise analysis of the code via the AST it builds internally. Our custom checks\nare employed through the use of a dynamic library which is loaded via the -load argument to\nclang-tidy. SDP and other teams plan to implement mongodb customized checks. If you are interested\nin implementing checks that can help enforce our standards in the codebase (or even just certain\ncomponents in the codebase), please reach out for more info.\n\nThe basics of implementing a check are in the\n[clang docs](https://releases.llvm.org/12.0.1/tools/clang/tools/extra/docs/clang-tidy/Contributing.html).\nIf you are planning to implement additional checks, it is highly recommended to look at the\n[existing clang tidy checks](https://github.com/llvm/llvm-project/tree/llvmorg-12.0.1/clang-tools-extra/clang-tidy)\nas reference starting material. Note that we use v4 toolchain with clang 12.0.1 and the clang tidy\ncheck API is subject to change between clang tidy versions. Also note that clang-tidy 12.0.1 release\ndoes not include the ability to load a module. This feature was backported into our v4 toolchain\nclang-tidy.\n\n#### Basic usage of the custom checks\n\nThe current directory contains the individual check source files, the main `MongoTidyModule.cpp`\nsource file which registers the checks, and the BUILD.bazel file responsible for building the check\nlibrary module. To build the custom checks use this command:\n\nThe bazel clang-tidy config will automatically build and use the custom checks module. To run clang\ntidy with the checks module use:\n\n bazel build --config=clang-tidy //src/mongo/...\n\n#### Adding check unittests\n\nA simple unittest framework is included with the checks so that they will automatically be run in\nquick, isolated, and minimal fashion. This allows for faster development and ensures the checks\ncontinue working.\n\nThe `test` directory contains the python unittest script, the test source files, and the BUILD.bazel\nwhich builds and runs the tests. To run all the custom tidy rules unittests use:\n\n bazel run mongo-tidy-test\n\nThis will run all the tests serially. Eventually we can improve this and they can be run in parallel\nbut currently they are serial. To run a specific test you can use python's unittest args, for\nexample:\n\nbazel run mongo-tidy-test -- -k test_MongoInvariantStatusIsOKCheck\n\n#### Writing your own check checklist\n\nBelow is a checklist of all the steps to make sure to perform when writing a new check.\n\n1. Implement the check in the respectively named `.h` and `.cpp` files.\n2. Add the check's `#include` to the `MongoTidyModule.cpp`.\n3. Register the check class with a check name in the `MongoTidyModule.cpp`.\n4. Add the `.cpp` file to the source list in the `BUILD.bazel` file.\n5. Write a unittest file named `tests/test_{CHECK_NAME}.cpp` and a config file\n `tests/test_{CHECK_NAME}.tidy_config` which minimally reproduces the issue.\n6. Add the test to the list of tests in `tests/BUILD.bazel`.\n7. Add a `def test_{CHECK_NAME}():` function to the `MongoTidyCheck_unittest.py` file which finds\n the expected error output in the stdout. Reference the other check functions for details.\n8. Run the bazel build with `bazel run mongo-tidy-test -- -k test_{CHECK_NAME}` to run the newly\n created test.\n\n#### Questions and Troubleshooting\n\nIf you have any questions please reach out to the `#ask-devprod-build` slack channel.\n","src/mongo/tools/workload_simulation/throughput_probing/README.md":"# Throughput Probing Simulations\n\nThis directory provides code for an executable `throughput_probing_simulator` that tests our\nthroughput probing algorithm used for execution control under a simulated workload. The workload\noutput consists of graphs showing the actual and optimal ticket allocations over time.\n\nThe rough workflow for an individual simulation is:\n\n1. Specify an optimal concurrency level, and the throughput at that concurrency level.\n2. Provide a well-behaved model for what throughput we will observe at different concurrency levels,\n and what operation latencies would produce that throughput.\n3. Use that model to specify a workload driver which simulates operations with the given latencies\n based on the current concurrency level selected by the throughput probing algorithm.\n4. Run the mock workload for specified duration.\n\n## File Structure\n\nNew workloads can be added in [`workloads.cpp`](workloads.cpp)\n\nThe existing `TicketedWorkloadDriver` is quite flexible, and should suffice for most workloads by\nsimply tuning the workload characteristics, runtime, etc. New workload characterstic types can be\ndefined in [`workload_characteristics.h`](../workload_characteristics.h).\n","src/third_party/wiredtiger/.claude/agents/wt-build.md":"---\nname: wt-build\ndescription: Use this agent when WiredTiger C/C++ source or test code has changed and the CMake build needs verification. Typical triggers include verifying a fresh edit compiles before running tests, a pre-commit sanity check after touching files under `src/` or `test/` (Catch2, csuite, cppsuite, format, etc.), and confirming a newly added source or test file is wired into the build.\ntools: [\"Bash\", \"Read\", \"Glob\", \"Grep\"]\nmodel: haiku\ncolor: yellow\n---\n\nYou are a build runner for WiredTiger. Compile the code with CMake and report the result. Be terse.\n\n## Procedure\n\n1. **Configure if needed.** If `build/CMakeCache.txt` exists, skip — respect the caller's existing configuration. Otherwise:\n ```\n cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug\n ```\n Default to `-DCMAKE_BUILD_TYPE=Debug` unless the caller specifies a different build type. Drop `-G Ninja` if `ninja` is not installed. Do not add other `-D` flags unless the caller asks; team members configure their own builds.\n\n2. **Pick a target.** If the caller named a CMake target, use it. Otherwise build everything.\n\n3. **Build**, redirecting output to a log file. The unfiltered output is large — never let it stream into your context:\n ```\n cmake --build build --parallel --target > build/last-build.log 2>&1\n ```\n Omit `--target ` for the fallback case. Report which target you built (or `all`) in the success/failure output so the caller can verify the scope.\n\n4. **Report.** On success, emit `SUCCESS` plus the target built and the last line of the log. On failure, emit `FAILED` plus the target and `file:line` for each error pulled from `build/last-build.log`. Use a grep that covers both GNU and macOS linker output:\n ```\n grep -E \"error:|undefined reference|Undefined symbols|ld: symbol|No such file|fatal error\" build/last-build.log | head -20\n ```\n\n## Edge cases\n\n- **Stale build directory.** If configure succeeds but the build fails with errors that look like missing files the caller just deleted (e.g. `No such file or directory` on a removed source), suggest the caller re-run `cmake -B build -G Ninja` or wipe `build/` — do not delete it yourself.\n- **Interrupted build.** If `cmake --build` exits non-zero with no errors in the log (e.g. SIGINT), report `FAILED — build interrupted, no errors logged` rather than inventing errors.\n- **Configure failure.** If the initial `cmake -B build` fails, report `FAILED` with the cmake error and stop; do not attempt to build.\n\n## Output format\n\n**On success:**\n```\nSUCCESS (target: ) — \n```\n\n**On failure:**\n```\nFAILED (target: )\n\nErrors:\n src/foo.c:123: error: 'bar' undeclared\n src/baz.c:45: error: ...\n\nLog: build/last-build.log\n```\n","src/mongo/db/commands/query_cmd/README.md":"# Parsing\n\n## Overview\n\nThe query system's parsing layer has two main components:\n\n1. [Command Parsing and Validation](#command-parsing-and-validation) is responsible for parsing the\n arguments to each command, verifying the expected number of arguments, and checking their types.\n1. [Query Language Parsing and Validation](#query-language-parsing-and-validation) is responsible\n for more query-specific parsing. This includes (but is not limited to) parsing query predicates\n and aggregation pipelines.\n\nOverall, the parsing layer translates from a client-facing command (e.g. find or aggregate) to a\nparsed command object (e.g. `ParsedFindCommand` or `Pipeline`). These parsed command objects are\nthen normalized to form the input of query planning: `CanonicalQuery`,\n[if possible](#parsing-aggregations).\n\n> ### Aside: `CanonicalQuery`\n>\n> A\n> [`CanonicalQuery`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/query/canonical_query.h#L72)\n> is a container that represents a parsed and normalized query. This includes features such as the\n> query's `filter`, `projection`, and `sort` elements. See\n> [here](../../query/README_logical_models.md#canonicalquery) for more information regarding\n> `CanonicalQuery` and its normalization.\n\n## Command Parsing and Validation\n\nThe QO team maintains the following commands:\n\n- Category 1: Basic Read Queries\n - `find`\n - `distinct`\n - `count`\n- Category 2: Aggregations\n - `aggregate`\n - `mapReduce`\n - Note: `mapReduce` was deprecated in MongoDB v5.0 in favor of standard aggregation.\n- Category 3: Write Queries\n - `insert`\n - `delete`\n - `update`\n - `findAndModify`\n\nEach command starts in a class that inherits from the\n[`Command`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/commands.h#L436)\nabstract class. These commands all live in the [`src/mongo/db/commands/`](/src/mongo/db/commands)\ndirectory. For example:\n\n- `FindCmd` lives in [find_cmd.cpp](/src/mongo/db/commands/query_cmd/find_cmd.cpp)\n- `aggregate`'s command (`AggregateCommand`) lives in\n [`aggregate_command.cpp`](/src/mongo/db/commands/query_cmd/aggregate_command.cpp).\n\nFirst, we piece apart the command into its components. We don't yet try to understand the meaning of\nthe more complex MQL arguments, such as find's `filter`, `projection`, and `sort` arguments, or the\nindividual stages in `aggregate`'s `pipeline` argument.\n\n> ### Aside: Command Parsing vs. Query Parsing\n>\n> The overall parsing layer reflects this hierarchy:\n>\n> 1. A valid bytestring may contain a possibly valid `BSON`, extracted using a **BSON parser**.\n> 1. A valid `BSON` may contain a possibly valid **command**, extracted using a\n> [**command parser**](#aside-the-interface-definition-language).\n> 1. A valid command may contain a possibly valid **query**, extracted using an\n> [**MQL parser**](#query-language-parsing-and-validation).\n>\n> At this point, we are considering the second layer, from `BSON` to `Command`.\n\nFor example, given this find query:\n\n```\ndb.c.find({$or: [{a: {$lt: 2}}, {a: 6}]}).sort({a: 1}).limit(5);\n```\n\nwe generate a C++ struct that stores `filter`, `sort`, and `limit` as member variables. Note that\n`filter` is left as a `BSONObj`; we don't yet \"know\" that it contains a `$or`. Rather than manually\nwriting the conversion code, we use an **Interface Definition Language** (IDL) tool to generate the\nparser and output a corresponding C++ struct. In the `find` case, `find_command.idl` generates\n`find_command_gen.h` and `find_command_gen.cpp` and by extension, a `FindCommandRequestBase` struct.\n\n> ### Aside: The Interface Definition Language\n>\n> Below is a simplified snippet of the relevant portion of `find_command.idl`. The full file can be\n> viewed [here](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/find_command.idl).\n>\n> ```yaml\n> commands:\n> find:\n> cpp_name: FindCommandRequestBase\n> command_name: find\n> description: \"A struct representing the find command\"\n> fields:\n> filter:\n> description: \"The query predicate. If unspecified, then all documents in the collection\n> will match the predicate.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> sort:\n> description: \"The sort specification for the ordering of the results.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> limit:\n> description: \"The maximum number of documents to return.\"\n> type: safeInt64\n> optional: true\n> validator: { gte: 0 }\n> stability: stable\n> ```\n>\n> This file (specified in a YAML format) is used to generate C++ code that will in turn create a\n> `FindCommandRequestBase`. Our build system will run a python tool to parse this YAML and spit out\n> C++ code which is then compiled and linked. This code is left in a file ending with '\\_gen.h' or\n> '\\_gen.cpp' (here `find_command_gen.cpp`). The YAML includes specifications of each field, such as\n> its type, whether it is optional, and any default values. The generated file will have getter and\n> setter member functions and will return a `boost::optional` for optional fields. Now, we have a\n> `FindCommandRequestBase` struct that neatly contains C++ members for each of the components of our\n> query.\n\n### Additional Setup Before MQL Processing\n\n#### `ExpressionContext`\n\nAn\n[**`ExpressionContext`**](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/pipeline/expression_context.h#L132)\nstores various pieces of state and settings that are pertinent throughout the lifespan of a query\nbut are not necessarily relevant to other types of operations. This includes elements such as the\ncollation, a time zone database, and other configuration flags (feature flags, query knobs, etc.).\nEach command initializes its own `ExpressionContext`; our `find` example does so\n[here](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L191).\n\n#### Non-IDL Command Validation\n\nOccasionally, the IDL parsers will not be able to express certain command constraints. For example,\nthe `findAndModify` command cannot specify `true` for both `remove` and `new`, but the\n[IDL parser](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/write_ops/write_ops.idl#L533)\nalone cannot restrict the user from doing this. In these cases, we add a\n[`validate()`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_and_modify.cpp#L133)\nfunction to perform these final checks.\n\n## Query Language Parsing and Validation\n\n### Parsing Read Queries: Find, Distinct, and Count\n\n#### Parsing Find\n\nAs discussed above, the IDL handles creation of a `FindCommandRequest`. With this\n`FindCommandRequest` struct, we can now call\n[`parsed_find_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196),\npassing in the `ExpressionContext` and a new struct of type `ParsedFindCommandParams`, which\ncontains the `FindCommandRequest` as a member. A few function calls later, we reach\n[`MatchExpressionParser::parse()`](https://github.com/mongodb/mongo/blob/0a68308f0d39a928ed551f285ba72ca560c38576/src/mongo/db/query/parsed_find_command.cpp#L186)\nwhich recursively parses the `BSONObj` `filter` component of our `FindCommandRequest` by using the\n`parse()` function for each type of `MatchExpression` node. This AST structure assembles the\n`filter` in an easily optimizable format, as each subclass `MatchExpression` node knows which\nrewrites are possible given their place in the AST. For more information on `MatchExpression`s, see\n[Logical Models](../../query/README_logical_models.md).\n\nAfter parsing our `MatchExpression` into a tree of `MatchExpression`s , we pass the full\n`MatchExpression` AST to a `ParsedFindCommand`. Note that `ParsedFindCommand`s only primary\ncomponents are the `filter`, `projection`, and `sort`; all other parameters (e.g. `limit`, `skip`,\n`batchSize`, etc.) are held as raw types in the `FindCommandRequest`.\n\nFinally, we\n[create](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196)\na `CanonicalQuery` by passing the `ParsedFindCommand` as an argument, thereby giving the\n`CanonicalQuery` the `filter`, `projection`, `sort`, and `FindCommandRequest`.\n\n#### Parsing Distinct and Count\n\nThe process of parsing `distinct` and `count` queries is nearly identical to that of `find`.\n\nDistinct queries are parsed by IDL into a `DistinctCommandRequest`, which is in turn converted into\na `ParsedDistinctCommand` by\n[`parsed_distinct_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_distinct_command.cpp#L132).\nIf a `filter` exists on the command, it is parsed using `MatchExpressionParser::parse()` like\n`find`. We then create a `CanonicalQuery` by an equivalent process to find, and\n[add a `CanonicalDistinct`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/parsed_distinct_command.cpp#L277)\nproperty to the `CanonicalQuery` with the details of the `distinct` query, such as its distinct key.\n\nCount queries are parsed using `ParsedFindCommand`'s\n[`parseFromCount()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_find_command.cpp#L346)\nfunction, which converts a `CountCommandRequest` into a `FindCommandRequest` and uses the same logic\nas `find` thereafter.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s1[\" \"]\n n1[\"Find\"]\n n2[\"Distinct\"]\n n3[\"Count\"]\n end\n n1 --> n10[\"IDL Parsing\"]\n n2 --> n10\n n3 --> n10\n n10 --> n11[\"FindCommandRequest\"] & n12[\"DistinctCommandRequest\"]\n n10 --> n21[\"CountCommandRequest\"]\n n13[\"ParsedFindCommand\"] --> n17[\"CanonicalQuery\"]\n n19[\"ParsedDistinctCommand\"] --> n17\n n21 -- parseFromCount() --> n11\n n11 -- \"parsed_find_command::parse()
MatchExpressionParser::parse()\" --> n13\n n12 -- \"parsed_distinct_command::parse()
MatchExpressionParser::parse()\" --> n19\n\n n10@{ shape: extract}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Aggregations\n\nAfter producing an `AggregateCommandRequest` via IDL, the request is\n[passed and parsed](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_pipeline.h#L70)\ninto a `LiteParsedPipeline`.\n\n> ### Aside: `LiteParsedPipeline`\n>\n> A `LiteParsedPipeline` is a simple model of an aggregation pipeline that is constructed through a\n> [semi-parse](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_document_source.h#L145)\n> that proceeds just enough to tease apart the stages that are involved. `LiteParsedPipeline`s do\n> not verify that the input is well-formed; instead, they can be used to _inspect_ queries before\n> building a full model of the user's pipeline.\n>\n> - For example, on systems running with authorization, the `$currentOp` aggregation stage requires\n> that the user has access that includes the\n> [`inprog`](https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-inprog)\n> privilege action. That means that if our `LiteParsedPipeline` finds a `$currentOp` that does not\n> satisfy the\n> [necessary privileges](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_current_op.h#L105),\n> we can\n> [return an error](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/auth/authorization_checks.cpp#L90)\n> and avoid the more expensive `DocumentSource` parsing process.\n\nAfter confirming that the `LiteParsedPipeline` satisfies all the necessary permissions, the full\n`AggregateCommandRequest` is passed to\n[`Pipeline::parseCommon()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L213)\nas a vector of pipeline stages (represented as raw `BSONObj`s). Each pipeline stage is then\nre-parsed using\n[`DocumentSource::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.cpp#L101),\nwhich calls on the `DocumentSource::createFromBson()` parser for each stage. At the time of\nthis writing, this double parse happens for all stages, but\n[SPM-4362](https://jira.mongodb.org/browse/SPM-4362) is aiming to make it possible to 'upgrade' a\n`LiteParsedPipeline` to a full `Pipeline` without re-parsing from raw BSON. We will prototype this\ncapability but not replace all existing stage's parsing implementations. This will be important for\nextensions processing though - it's a step towards a world where full parsing and query shape\ngeneration happen earlier in the process.\n\n> ### Aside: `DocumentSource`\n>\n> A `DocumentSource` represents one stage of an aggregation pipeline. Each `DocumentSource` lives in\n> its own file with this form:\n> [`src/mongo/db/pipeline/document_source_`](https://github.com/mongodb/mongo/tree/master/src/mongo/db/pipeline),\n> with a\n> [`REGISTER_DOCUMENT_SOURCE`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.h#L99)\n> macro at the top. Each `DocumentSource` also features a `createFromBson()` function; this is the\n> main parsing function for each `DocumentSource`. By registering each document source with its lite\n> parsing and full parsing functions, we can recursively parse the entire pipeline, stage by stage.\n>\n> Not all `DocumentSource`s get parsed into their own stages. Major stages like `$match` do have a\n> [`createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_match.cpp#L594)\n> that returns a `DocumentSourceMatch`, but some stages are aliases for other `DocumentSource`s.\n>\n> - For example,\n> [`DocumentSourceBucket::createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_bucket.cpp#L74)\n> returns two `DocumentSource`s: a `$group` stage and a `$sort` stage by calling on\n> `DocumentSourceGroup` and `DocumentSourceSort`'s respective `createFromBson()` functions.\n\nThe\n[result](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L233)\nof this parsing is a\n[`Pipeline`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.h#L110)\nobject that contains a list of parsed `DocumentSource`s as a member. Our final goal, however, is to\nget a `CanonicalQuery`. This may or may not be possible depending on the type of aggregation. For\nexample:\n\n> ```\n> // This query fully undergoes optimization as a CanonicalQuery.\n> db.c.aggregate([{$match: {a: {$gte: 2, $lte: 10}}}, {$sort: {a: 1}}, {$limit: 5}])\n> // This query is not canonicalizable.\n> db.c.aggregate([{$addFields: {b: {$add: [\"$a\", 1]}}}])\n> ```\n\nIf some component of the `Pipeline` can become a `CanonicalQuery` (i.e. it contains a filter, sort,\nprojection, etc.), we will\n[create a `CanonicalQuery`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline_d.cpp#L1144)\nfor this `Pipeline`, and proceed with optimization and execution as we would with a find command.\n\n#### Parsing MapReduce\n\nAfter parsing into a `MapReduceCommandRequest` via IDL, the `MapReduceCommandRequest` is\n[translated](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/map_reduce_agg.cpp#L187)\ninto an equivalent pipeline using the same `DocumentSource` parsing functions as aggregation.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s2[\" \"]\n n4[\"Aggregate\"]\n n5[\"MapReduce\"]\n end\n n4 --> n21[\"IDL Parsing\"]\n n5 --> n21\n n21 --> n22[\"AggregateCommandRequest\"] & n30[\"MapReduceCommandRequest\"]\n n22 --> n23[\"LiteParsedPipeline\"]\n n23 -- Authorization Checks --> n22\n n28[\"Pipeline\"] --> n32[\"Is some component of the Pipeline canonicalizable?\"]\n n32 -- No --> n33>\"DocumentSourceExecution\"]\n n22 -- Pipeline::parseCommon()
DocumentSource::parse() --> n31[\"DocumentSources\"]\n n30 --> n31\n n31 -- \"DocumentSource<Stage>::createFromBson()\" --> n28\n n32 -- \"Yes
createCanonicalQuery()\" --> n17[\"CanonicalQuery\"]\n\n n21@{ shape: extract}\n n32@{ shape: diam}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Write Queries\n\nInsert, Delete, Update, and FindAndModify are all parsed by IDL as described above and converted\ninto a `BulkWriteCommandRequest`, `DeleteRequest`, `UpdateRequest`, `FindAndModifyCommandRequest`,\nrespectively.\n\nInserts are internally\n[represented](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/bulk_write.idl#L324)\nas a `BulkWriteCommandRequest` which contains an array of `BulkWriteInsertOp`s. No query\noptimization is needed for inserts beyond parsing, since insert is a write-only operation.\n\n`DeleteRequest`s are passed to `parsed_delete_command::parse()`, which parses them into\n`ParsedDelete` objects. `parsed_delete_command::parse()` uses `parseWriteQueryToParsedFindCommand()`\nto parse the `filter` component of the write query. This shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedDelete`. Subsequently, the `ParsedDelete` objects are passed to `CanonicalDelete::make()`,\nwhich constructs a `CanonicalDelete` consisting of a `CanonicalQuery`.\n\n`UpdateRequest`s are passed to `parsed_update_command::parse()`, which parses them into\n`ParsedUpdate` objects. `parsed_update_command::parse()` uses\n`parseWriteQueryToParsedFindCommand()`, which shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedUpdate`. Subsequently, the `ParsedUpdate` objects are passed to `CanonicalUpdate::make()`,\nwhich constructs a `CanonicalUpdate` consisting of a `CanonicalQuery`.\n\n`FindAndModifyCommandRequest`s can contain both find and update/delete syntax. For this reason, the\nquery portion is entirely delegated to the `find` query parser. The update or delete portion is\ntranslated into a `CanonicalUpdate` or `CanonicalDelete`, each of which uses the corresponding\ncodepath henceforth.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s3[\" \"]\n n6[\"Insert\"]\n n7[\"Delete\"]\n n8[\"Update\"]\n n9[\"FindAndModify\"]\n end\n n6 --> n31[\"IDL Parsing\"]\n n7 --> n31\n n8 --> n31\n n9 --> n31\n n31 --> n32[\"BulkWriteCommandRequest\"] & n34[\"DeleteRequest\"] & n35[\"UpdateRequest\"] & n39[\"FindAndModifyCommandRequest\"]\n n32 --o n33[\"BulkWriteInsertOp\"]\n n34 -- \"parsed_delete_command::parse()\" --> n36[\"ParsedDelete\"]\n n35 -- \"parsed_update_command::parse()\" --> n37[\"ParsedUpdate\"]\n n39 --> n36\n n39 --> n37\n n36 -- \"CanonicalDelete::make()\" --> n40[\"CanonicalDelete\"]\n n37 -- \"CanonicalUpdate::make()\" --> n41[\"CanonicalUpdate\"]\n n40 --o n17[\"CanonicalQuery\"]\n n41 --o n17\n\n n17@{ shape: dbl-circ}\n n31@{ shape: extract}\n```\n\n---\n\n[Return to Cover Page](../../query/README_QO.md)\n","src/mongo/tools/workload_simulation/README.md":"# Workload Simulation\n\nThis directory provides code for generating `*_simulator` executables that test various components\nof the system under a simulated workload. The executables produces log output that can be converted\ninto graphs plotting metrics collected over time using `process_logs.py`.\n\nThe simulations themselves are carried out using an event queue and a mock clock. Workload drivers\nspawn and manage actor threads that are responsible for sending _event_ requests to the queue, where\neach request is tied to a time. The queue is responsible for advancing the clock appropriately and\nnotifying the actor threads when the clock has reached the appropriate time for their requests to be\nprocessed. Additional, non-actor threads can similarly wait for specific times during the simulation\nby registering _observer_ requests that are maintained in a separate internal queue.\n\nMore specifically:\n\n1. The event queue waits until it has received an _event_ request from each reported actor thread.\n2. When it is sufficiently full, the queue determines the minimum time of a queued _event_ request,\n and advances the mock clock to that time.\n3. The queue then notifies any threads waiting on either _event_ or _observer_ requests at or before\n the current time.\n\nThe _observer_ mechanism is used to trigger periodic metric reporting for the log output. It may\nalso be used by workload drivers to trigger periodic jobs.\n\n## Defining a Simulation\n\nThe [`simulation.h`](simulation.h) header defines a `SIMULATION` macro that functions similarly to\nthe `TEST_F` macro in our unittesting framework. It expects the first parameter to be the name of a\nfixture class derived from `mongo::workload_simulation::Simulation`. The second parameter is the\nname of the workload, and any additional parameters will be passed as input to the constructor of\nthe fixture class.\n\nA C++ file that defines these macros can be compiled using the `simulator_main` bazel target to link\nthe relevant `main` implementation that runs all the workloads defined using the macro.\n\n## Generating Visualizations\n\nA `*_simulator` executable simply runs all selected workloads and outputs logs to stdout. These logs\ncan be piped to `process_logs.py` to generate graphs. Ex.\n\n```\n$ throughput_probing_simulator | process_logs.py -o ~/sim_output\n```\n","src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md":"# rootAnalysis Documentation\n\nPath: `src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md)",".cursorrules (nodejs-mongodb-cursorrules-prompt-file-tutorial.mdc)":"---\ndescription: \"Cursor rules for Node.js development with MongoDB integration.\"\nglobs: **/*\nalwaysApply: false\n---\nTech Stack:\n\nBackend: Node.js with Express.js\n\nDatabase: MongoDB with Mongoose ODM\n\nFrontend: React.js (for admin panel, if required)\n\nAuthentication: JSON Web Tokens (JWT)\n\nVersion Control: Git\n\nDeployment: Docker (optional)\n\nPrecision in User Requirements:\n\nStrictly adhere to specified user flow and game rules.\n\nStrategy: \n\nSummarize the pick submission process and outline the API endpoint and business logic in pseudocode before coding.\n\nStrategic Planning with Pseudocode:\n\nBegin each feature with detailed pseudocode.\n\nExample: Provide pseudocode for the weekly scoring process, detailing steps from game result input to entry status updates.\n\nCode Quality:\n\nEnsure secure, efficient code following RESTful API best practices.\n\nImplement proper error handling and input validation.\n\nUser Flow:\n\nUsers browse available Pools\n\nSubmit up to 3 Requests per Pool\n\nComplete payment for Requests\n\nAdmin approves/rejects Requests\n\nApproved Requests become Entries\n\nEntry Management:\n\nEach user can have up to 3 Entries per Pool\n\nEntries are numbered 1, 2, 3\n\nPicks are made and tracked separately for each Entry\n\nPick Management:\n\nUsers make Picks for each Entry separately\n\nPicks can be updated until deadline (game start or 1PM Sunday of the current week of the pick)\n\nScoring and Ranking:\n\nPicks scored after games complete\n\nWin: Entry moves to next week\n\nLoss: Entry eliminated from Pool\n\nEach Entry ranked separately in Pool standings\n\nResults and Standings:\n\nUsers view Picks/scores for each Entry separately\n\nPool standings show all Entries (multiple per User possible)\n\nPool members can view all Picks after scoring\n\nKey Implementation Points:\n\nLimit Requests to 3 per User per Pool\n\nTrack Requests and Entries separately (numbered 1, 2, 3)\n\nImplement payment status tracking in Request model\n\nCreate Entry only after admin approval and payment completion\n\nAdmin interface for managing and approving Requests\n\nImplement state transitions (Request: pending -> approved -> Entry created)\n"},"items":[{"name":"AGENTS.md","path":"jstests/AGENTS.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/jstests/AGENTS.md","title":"jstests - AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"## JavaScript Test Code Conventions\n\n### Assertion Library\n\nALWAYS use our own assertion library that is defined at `src/mongo/shell/assert.js` and\nautomatically loaded into the global scope before running each test.\n\nALWAYS wrap commands with `assert.commandWorked()`, unless failures are expected and checked. Use\n`assert.writeOK()` when working with legacy bulk write APIs.\n\nUse `assert.soon()` only for asynchronous or eventually-consistent conditions.\n\n### Mocha Style for New Test Files\n\nUse the mocha style to structure test cases in newly added test files. The\n`jstests/libs/mochalite.js` module implements `describe`, `it`, `before`, `beforeEach`, `afterEach`,\nand `after`. Import only what you need. Feel free to add other mocha helper functions to\n`jstests/libs/mochalite.js` if they would make the current test cleaner.\n\n```js\nimport {before, describe, it} from \"jstests/libs/mochalite.js\";\n\ndescribe(\"feature under test\", function () {\n before(function () {\n /* one-time setup */\n });\n it(\"does X\", function () {\n /* ... */\n });\n});\n```\n\n### Use JSON-Conformant Object Serialization in Logs\n\nPass objects to the `attr` parameter of assertion and logging functions instead of concatenating\n`tojson()` into the message string. Most `assert.*` functions accept an `attr` object as their last\nargument.\n\n```js\n// Bad — tojson() in the message string\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing: \" + tojson(cursor));\n\n// Good — object passed via attr\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing\", {cursor});\n```\n\nFor logging:\n\n```js\n// Bad\njsTest.log.info(\"got cursor: \" + tojson(cursor));\n\n// Good\njsTest.log.info(\"got cursor\", {cursor});\n```\n\n### Resource and Settings Cleanup\n\nALWAYS clean up resources and settings immediately after they are no longer needed. Examples of\nserver resources are cursors and collections. Examples of settings are server parameters and test\nframework settings stored in the global `TestData` object.\n","isInternal":false,"tokens":454,"sizeBytes":1983},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Copilot instructions for this repository\n\n## Flag likely CVE / security-vulnerability fixes\n\nCommits on `master` are automatically synced to the public `mongodb/mongo` repository. A security\nfix that lands on `master` before the corresponding CVE is disclosed publicly reveals the\nvulnerability while released versions are still unpatched.\n\nWhen reviewing a pull request, flag it prominently if it looks like a fix for a security\nvulnerability or CVE. Signals include:\n\n- The PR, commit message, or linked ticket mentions a CVE, \"vulnerability\", \"security fix\",\n \"embargo\", or a security-team ticket.\n- The change fixes spoofing, forgery, injection, authentication/authorization bypass, privilege\n escalation, out-of-bounds access, or similar exploitable behavior.\n- The change hardens a trust boundary (e.g. validating previously trusted input from the network, a\n proxy header, or another node) or corrects audit-log attribution.\n- Documentation changes that describe how existing behavior can be abused by an attacker.\n\nIf any of these apply, add a review comment telling the author:\n\n> This PR looks like it may fix a security vulnerability. Because `master` is synced to the public\n> repository, this change must only be merged after the corresponding CVE has been publicly\n> disclosed and fixed releases are available. Confirm disclosure timing with the security team\n> before merging.\n\nDo not speculate about exploit details in review comments; just flag the disclosure-timing concern.\n","isInternal":false,"tokens":309,"sizeBytes":1498},{"name":"README.md","path":"buildscripts/resmokelib/extensions/README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/buildscripts/resmokelib/extensions/README.md","title":"extensions Documentation","category":"plugin-manifest","format":"markdown","content":"# Extensions\n\nThis module provides utilities for setting up and configuring MongoDB extensions in resmoke test\nsuites.\n\n## Overview\n\nExtensions are dynamically loaded shared objects (`.so` files) that provide additional functionality\nto MongoDB. The utilities in this folder can handle:\n\n1. Discovering extension `.so` files in build directories\n2. Generating `.conf` configuration files for extensions\n3. Cleaning up configuration files after tests\n\n## Configuration File Generation in Tests\n\nExtension `.conf` files are YAML configuration files that tell the server how to load an extension.\nThey contain:\n\n- `sharedLibraryPath`: Path to the `.so` file\n- `extensionOptions`: Optional configuration parameters for the extension\n\nFor example:\n\n```yaml\n# foo.conf\nsharedLibraryPath: /path/to/libfoo_mongo_extension.so\nextensionOptions:\n someSetting: \n```\n\n### How Config Files Are Generated\n\nThe `generate_extension_configs.py` module creates `.conf` files:\n\n1. Receives a list of `.so` file paths (either from automatic discovery via\n `find_and_generate_extension_configs.py`, or manually via `--so-files` command-line argument)\n2. For each `.so`, creates a `.conf` file in the temp directory (`/tmp/mongo/extensions/`)\n3. Looks up corresponding extension options from\n `src/mongo/db/extension/test_examples/configurations.yml`, if any are specified\n4. Writes the config file with `sharedLibraryPath` and any `extensionOptions`\n\n### Automatic Discovery and Generation\n\nThe `find_and_generate_extension_configs.py` module combines discovery and generation:\n\n1. Searches for `*_mongo_extension.so` files in build directories:\n - **Evergreen:** `dist-test/lib/`\n - **Local:** `bazel-bin/install-dist-test/lib/` or `bazel-bin/install-extensions/lib/`\n2. Generates `.conf` files with a unique UUID suffix to avoid collisions\n3. Adds the `loadExtensions` parameter to mongod/mongos options\n","isInternal":false,"tokens":417,"sizeBytes":1900},{"name":"README.md","path":"src/mongo/tools/mongo_tidy_checks/README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/mongo/tools/mongo_tidy_checks/README.md","title":"mongo_tidy_checks Documentation","category":"plugin-manifest","format":"markdown","content":"# MongoDB Custom Clang Tidy module\n\nThe MongoDB server includes a custom clang-tidy module which allows server developers to write\ncustom clang-tidy rules for enforcement of best practices, finding bugs, and\n[large scale refactoring](https://www.youtube.com/watch?v=UfLH7dORav8). Checks for these rules will\nbe run as part of the commit queue and locally with the\n[clang-tidy vscode plugin](https://wiki.corp.mongodb.com/display/HGTC/Remote+Development+with+Visual+Studio+Code+%28vscode%29+for+MongoDB)\nor the clang-tidy command line.\n\nClang-tidy allows precise analysis of the code via the AST it builds internally. Our custom checks\nare employed through the use of a dynamic library which is loaded via the -load argument to\nclang-tidy. SDP and other teams plan to implement mongodb customized checks. If you are interested\nin implementing checks that can help enforce our standards in the codebase (or even just certain\ncomponents in the codebase), please reach out for more info.\n\nThe basics of implementing a check are in the\n[clang docs](https://releases.llvm.org/12.0.1/tools/clang/tools/extra/docs/clang-tidy/Contributing.html).\nIf you are planning to implement additional checks, it is highly recommended to look at the\n[existing clang tidy checks](https://github.com/llvm/llvm-project/tree/llvmorg-12.0.1/clang-tools-extra/clang-tidy)\nas reference starting material. Note that we use v4 toolchain with clang 12.0.1 and the clang tidy\ncheck API is subject to change between clang tidy versions. Also note that clang-tidy 12.0.1 release\ndoes not include the ability to load a module. This feature was backported into our v4 toolchain\nclang-tidy.\n\n#### Basic usage of the custom checks\n\nThe current directory contains the individual check source files, the main `MongoTidyModule.cpp`\nsource file which registers the checks, and the BUILD.bazel file responsible for building the check\nlibrary module. To build the custom checks use this command:\n\nThe bazel clang-tidy config will automatically build and use the custom checks module. To run clang\ntidy with the checks module use:\n\n bazel build --config=clang-tidy //src/mongo/...\n\n#### Adding check unittests\n\nA simple unittest framework is included with the checks so that they will automatically be run in\nquick, isolated, and minimal fashion. This allows for faster development and ensures the checks\ncontinue working.\n\nThe `test` directory contains the python unittest script, the test source files, and the BUILD.bazel\nwhich builds and runs the tests. To run all the custom tidy rules unittests use:\n\n bazel run mongo-tidy-test\n\nThis will run all the tests serially. Eventually we can improve this and they can be run in parallel\nbut currently they are serial. To run a specific test you can use python's unittest args, for\nexample:\n\nbazel run mongo-tidy-test -- -k test_MongoInvariantStatusIsOKCheck\n\n#### Writing your own check checklist\n\nBelow is a checklist of all the steps to make sure to perform when writing a new check.\n\n1. Implement the check in the respectively named `.h` and `.cpp` files.\n2. Add the check's `#include` to the `MongoTidyModule.cpp`.\n3. Register the check class with a check name in the `MongoTidyModule.cpp`.\n4. Add the `.cpp` file to the source list in the `BUILD.bazel` file.\n5. Write a unittest file named `tests/test_{CHECK_NAME}.cpp` and a config file\n `tests/test_{CHECK_NAME}.tidy_config` which minimally reproduces the issue.\n6. Add the test to the list of tests in `tests/BUILD.bazel`.\n7. Add a `def test_{CHECK_NAME}():` function to the `MongoTidyCheck_unittest.py` file which finds\n the expected error output in the stdout. Reference the other check functions for details.\n8. Run the bazel build with `bazel run mongo-tidy-test -- -k test_{CHECK_NAME}` to run the newly\n created test.\n\n#### Questions and Troubleshooting\n\nIf you have any questions please reach out to the `#ask-devprod-build` slack channel.\n","isInternal":false,"tokens":929,"sizeBytes":3921},{"name":"README.md","path":"src/mongo/tools/workload_simulation/README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/mongo/tools/workload_simulation/README.md","title":"workload_simulation Documentation","category":"plugin-manifest","format":"markdown","content":"# Workload Simulation\n\nThis directory provides code for generating `*_simulator` executables that test various components\nof the system under a simulated workload. The executables produces log output that can be converted\ninto graphs plotting metrics collected over time using `process_logs.py`.\n\nThe simulations themselves are carried out using an event queue and a mock clock. Workload drivers\nspawn and manage actor threads that are responsible for sending _event_ requests to the queue, where\neach request is tied to a time. The queue is responsible for advancing the clock appropriately and\nnotifying the actor threads when the clock has reached the appropriate time for their requests to be\nprocessed. Additional, non-actor threads can similarly wait for specific times during the simulation\nby registering _observer_ requests that are maintained in a separate internal queue.\n\nMore specifically:\n\n1. The event queue waits until it has received an _event_ request from each reported actor thread.\n2. When it is sufficiently full, the queue determines the minimum time of a queued _event_ request,\n and advances the mock clock to that time.\n3. The queue then notifies any threads waiting on either _event_ or _observer_ requests at or before\n the current time.\n\nThe _observer_ mechanism is used to trigger periodic metric reporting for the log output. It may\nalso be used by workload drivers to trigger periodic jobs.\n\n## Defining a Simulation\n\nThe [`simulation.h`](simulation.h) header defines a `SIMULATION` macro that functions similarly to\nthe `TEST_F` macro in our unittesting framework. It expects the first parameter to be the name of a\nfixture class derived from `mongo::workload_simulation::Simulation`. The second parameter is the\nname of the workload, and any additional parameters will be passed as input to the constructor of\nthe fixture class.\n\nA C++ file that defines these macros can be compiled using the `simulator_main` bazel target to link\nthe relevant `main` implementation that runs all the workloads defined using the macro.\n\n## Generating Visualizations\n\nA `*_simulator` executable simply runs all selected workloads and outputs logs to stdout. These logs\ncan be piped to `process_logs.py` to generate graphs. Ex.\n\n```\n$ throughput_probing_simulator | process_logs.py -o ~/sim_output\n```\n","isInternal":false,"tokens":477,"sizeBytes":2321},{"name":"README.md","path":"src/mongo/tools/workload_simulation/throughput_probing/README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/mongo/tools/workload_simulation/throughput_probing/README.md","title":"throughput_probing Documentation","category":"plugin-manifest","format":"markdown","content":"# Throughput Probing Simulations\n\nThis directory provides code for an executable `throughput_probing_simulator` that tests our\nthroughput probing algorithm used for execution control under a simulated workload. The workload\noutput consists of graphs showing the actual and optimal ticket allocations over time.\n\nThe rough workflow for an individual simulation is:\n\n1. Specify an optimal concurrency level, and the throughput at that concurrency level.\n2. Provide a well-behaved model for what throughput we will observe at different concurrency levels,\n and what operation latencies would produce that throughput.\n3. Use that model to specify a workload driver which simulates operations with the given latencies\n based on the current concurrency level selected by the throughput probing algorithm.\n4. Run the mock workload for specified duration.\n\n## File Structure\n\nNew workloads can be added in [`workloads.cpp`](workloads.cpp)\n\nThe existing `TicketedWorkloadDriver` is quite flexible, and should suffice for most workloads by\nsimply tuning the workload characteristics, runtime, etc. New workload characterstic types can be\ndefined in [`workload_characteristics.h`](../workload_characteristics.h).\n","isInternal":false,"tokens":235,"sizeBytes":1206},{"name":"README.md","path":"src/third_party/gperftools/README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/third_party/gperftools/README.md","title":"gperftools Documentation","category":"plugin-manifest","format":"markdown","content":"\n\nDon't make manual changes to files in the dist/ or platform/ directories.\nSource code changes should be made in the mongodb-labs/gperftools repo.\nTweaks or reconfigurations of our third-party installation have to be\nmade in scripts/ or BUILD.bazel files, etc.\n\n== contents ==\n\n```\n src/third_party/\n gperftool-2.7/\n dist/ # 'make distdir' snapshot of mongodb-labs/gperftools\n platform/\n linux_x86_64/ # per platform directories\n include/ # headers used by consumers of gperftools\n internal/ # headers used in the compile of gperftools\n ... # other platforms: $os_$arch\n windows_x86_64/ # special case that's always regenerated, and always the same way.\n scripts/\n import.sh # regenerate the dist/ snapshot from git repo.\n host_config.sh # generate platform headers dir for the host and windows_x86_64.\n```\n\n","isInternal":false,"tokens":224,"sizeBytes":1013},{"name":"README.md","path":"src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md","title":"rootAnalysis Documentation","category":"plugin-manifest","format":"markdown","content":"# rootAnalysis Documentation\n\nPath: `src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md)","tokens":300,"sizeBytes":259},{"name":"README.md","path":"src/mongo/db/commands/query_cmd/README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/mongo/db/commands/query_cmd/README.md","title":"Command: /readme","category":"command-prompt","format":"markdown","content":"# Parsing\n\n## Overview\n\nThe query system's parsing layer has two main components:\n\n1. [Command Parsing and Validation](#command-parsing-and-validation) is responsible for parsing the\n arguments to each command, verifying the expected number of arguments, and checking their types.\n1. [Query Language Parsing and Validation](#query-language-parsing-and-validation) is responsible\n for more query-specific parsing. This includes (but is not limited to) parsing query predicates\n and aggregation pipelines.\n\nOverall, the parsing layer translates from a client-facing command (e.g. find or aggregate) to a\nparsed command object (e.g. `ParsedFindCommand` or `Pipeline`). These parsed command objects are\nthen normalized to form the input of query planning: `CanonicalQuery`,\n[if possible](#parsing-aggregations).\n\n> ### Aside: `CanonicalQuery`\n>\n> A\n> [`CanonicalQuery`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/query/canonical_query.h#L72)\n> is a container that represents a parsed and normalized query. This includes features such as the\n> query's `filter`, `projection`, and `sort` elements. See\n> [here](../../query/README_logical_models.md#canonicalquery) for more information regarding\n> `CanonicalQuery` and its normalization.\n\n## Command Parsing and Validation\n\nThe QO team maintains the following commands:\n\n- Category 1: Basic Read Queries\n - `find`\n - `distinct`\n - `count`\n- Category 2: Aggregations\n - `aggregate`\n - `mapReduce`\n - Note: `mapReduce` was deprecated in MongoDB v5.0 in favor of standard aggregation.\n- Category 3: Write Queries\n - `insert`\n - `delete`\n - `update`\n - `findAndModify`\n\nEach command starts in a class that inherits from the\n[`Command`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/commands.h#L436)\nabstract class. These commands all live in the [`src/mongo/db/commands/`](/src/mongo/db/commands)\ndirectory. For example:\n\n- `FindCmd` lives in [find_cmd.cpp](/src/mongo/db/commands/query_cmd/find_cmd.cpp)\n- `aggregate`'s command (`AggregateCommand`) lives in\n [`aggregate_command.cpp`](/src/mongo/db/commands/query_cmd/aggregate_command.cpp).\n\nFirst, we piece apart the command into its components. We don't yet try to understand the meaning of\nthe more complex MQL arguments, such as find's `filter`, `projection`, and `sort` arguments, or the\nindividual stages in `aggregate`'s `pipeline` argument.\n\n> ### Aside: Command Parsing vs. Query Parsing\n>\n> The overall parsing layer reflects this hierarchy:\n>\n> 1. A valid bytestring may contain a possibly valid `BSON`, extracted using a **BSON parser**.\n> 1. A valid `BSON` may contain a possibly valid **command**, extracted using a\n> [**command parser**](#aside-the-interface-definition-language).\n> 1. A valid command may contain a possibly valid **query**, extracted using an\n> [**MQL parser**](#query-language-parsing-and-validation).\n>\n> At this point, we are considering the second layer, from `BSON` to `Command`.\n\nFor example, given this find query:\n\n```\ndb.c.find({$or: [{a: {$lt: 2}}, {a: 6}]}).sort({a: 1}).limit(5);\n```\n\nwe generate a C++ struct that stores `filter`, `sort`, and `limit` as member variables. Note that\n`filter` is left as a `BSONObj`; we don't yet \"know\" that it contains a `$or`. Rather than manually\nwriting the conversion code, we use an **Interface Definition Language** (IDL) tool to generate the\nparser and output a corresponding C++ struct. In the `find` case, `find_command.idl` generates\n`find_command_gen.h` and `find_command_gen.cpp` and by extension, a `FindCommandRequestBase` struct.\n\n> ### Aside: The Interface Definition Language\n>\n> Below is a simplified snippet of the relevant portion of `find_command.idl`. The full file can be\n> viewed [here](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/find_command.idl).\n>\n> ```yaml\n> commands:\n> find:\n> cpp_name: FindCommandRequestBase\n> command_name: find\n> description: \"A struct representing the find command\"\n> fields:\n> filter:\n> description: \"The query predicate. If unspecified, then all documents in the collection\n> will match the predicate.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> sort:\n> description: \"The sort specification for the ordering of the results.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> limit:\n> description: \"The maximum number of documents to return.\"\n> type: safeInt64\n> optional: true\n> validator: { gte: 0 }\n> stability: stable\n> ```\n>\n> This file (specified in a YAML format) is used to generate C++ code that will in turn create a\n> `FindCommandRequestBase`. Our build system will run a python tool to parse this YAML and spit out\n> C++ code which is then compiled and linked. This code is left in a file ending with '\\_gen.h' or\n> '\\_gen.cpp' (here `find_command_gen.cpp`). The YAML includes specifications of each field, such as\n> its type, whether it is optional, and any default values. The generated file will have getter and\n> setter member functions and will return a `boost::optional` for optional fields. Now, we have a\n> `FindCommandRequestBase` struct that neatly contains C++ members for each of the components of our\n> query.\n\n### Additional Setup Before MQL Processing\n\n#### `ExpressionContext`\n\nAn\n[**`ExpressionContext`**](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/pipeline/expression_context.h#L132)\nstores various pieces of state and settings that are pertinent throughout the lifespan of a query\nbut are not necessarily relevant to other types of operations. This includes elements such as the\ncollation, a time zone database, and other configuration flags (feature flags, query knobs, etc.).\nEach command initializes its own `ExpressionContext`; our `find` example does so\n[here](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L191).\n\n#### Non-IDL Command Validation\n\nOccasionally, the IDL parsers will not be able to express certain command constraints. For example,\nthe `findAndModify` command cannot specify `true` for both `remove` and `new`, but the\n[IDL parser](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/write_ops/write_ops.idl#L533)\nalone cannot restrict the user from doing this. In these cases, we add a\n[`validate()`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_and_modify.cpp#L133)\nfunction to perform these final checks.\n\n## Query Language Parsing and Validation\n\n### Parsing Read Queries: Find, Distinct, and Count\n\n#### Parsing Find\n\nAs discussed above, the IDL handles creation of a `FindCommandRequest`. With this\n`FindCommandRequest` struct, we can now call\n[`parsed_find_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196),\npassing in the `ExpressionContext` and a new struct of type `ParsedFindCommandParams`, which\ncontains the `FindCommandRequest` as a member. A few function calls later, we reach\n[`MatchExpressionParser::parse()`](https://github.com/mongodb/mongo/blob/0a68308f0d39a928ed551f285ba72ca560c38576/src/mongo/db/query/parsed_find_command.cpp#L186)\nwhich recursively parses the `BSONObj` `filter` component of our `FindCommandRequest` by using the\n`parse()` function for each type of `MatchExpression` node. This AST structure assembles the\n`filter` in an easily optimizable format, as each subclass `MatchExpression` node knows which\nrewrites are possible given their place in the AST. For more information on `MatchExpression`s, see\n[Logical Models](../../query/README_logical_models.md).\n\nAfter parsing our `MatchExpression` into a tree of `MatchExpression`s , we pass the full\n`MatchExpression` AST to a `ParsedFindCommand`. Note that `ParsedFindCommand`s only primary\ncomponents are the `filter`, `projection`, and `sort`; all other parameters (e.g. `limit`, `skip`,\n`batchSize`, etc.) are held as raw types in the `FindCommandRequest`.\n\nFinally, we\n[create](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196)\na `CanonicalQuery` by passing the `ParsedFindCommand` as an argument, thereby giving the\n`CanonicalQuery` the `filter`, `projection`, `sort`, and `FindCommandRequest`.\n\n#### Parsing Distinct and Count\n\nThe process of parsing `distinct` and `count` queries is nearly identical to that of `find`.\n\nDistinct queries are parsed by IDL into a `DistinctCommandRequest`, which is in turn converted into\na `ParsedDistinctCommand` by\n[`parsed_distinct_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_distinct_command.cpp#L132).\nIf a `filter` exists on the command, it is parsed using `MatchExpressionParser::parse()` like\n`find`. We then create a `CanonicalQuery` by an equivalent process to find, and\n[add a `CanonicalDistinct`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/parsed_distinct_command.cpp#L277)\nproperty to the `CanonicalQuery` with the details of the `distinct` query, such as its distinct key.\n\nCount queries are parsed using `ParsedFindCommand`'s\n[`parseFromCount()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_find_command.cpp#L346)\nfunction, which converts a `CountCommandRequest` into a `FindCommandRequest` and uses the same logic\nas `find` thereafter.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s1[\" \"]\n n1[\"Find\"]\n n2[\"Distinct\"]\n n3[\"Count\"]\n end\n n1 --> n10[\"IDL Parsing\"]\n n2 --> n10\n n3 --> n10\n n10 --> n11[\"FindCommandRequest\"] & n12[\"DistinctCommandRequest\"]\n n10 --> n21[\"CountCommandRequest\"]\n n13[\"ParsedFindCommand\"] --> n17[\"CanonicalQuery\"]\n n19[\"ParsedDistinctCommand\"] --> n17\n n21 -- parseFromCount() --> n11\n n11 -- \"parsed_find_command::parse()
MatchExpressionParser::parse()\" --> n13\n n12 -- \"parsed_distinct_command::parse()
MatchExpressionParser::parse()\" --> n19\n\n n10@{ shape: extract}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Aggregations\n\nAfter producing an `AggregateCommandRequest` via IDL, the request is\n[passed and parsed](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_pipeline.h#L70)\ninto a `LiteParsedPipeline`.\n\n> ### Aside: `LiteParsedPipeline`\n>\n> A `LiteParsedPipeline` is a simple model of an aggregation pipeline that is constructed through a\n> [semi-parse](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_document_source.h#L145)\n> that proceeds just enough to tease apart the stages that are involved. `LiteParsedPipeline`s do\n> not verify that the input is well-formed; instead, they can be used to _inspect_ queries before\n> building a full model of the user's pipeline.\n>\n> - For example, on systems running with authorization, the `$currentOp` aggregation stage requires\n> that the user has access that includes the\n> [`inprog`](https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-inprog)\n> privilege action. That means that if our `LiteParsedPipeline` finds a `$currentOp` that does not\n> satisfy the\n> [necessary privileges](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_current_op.h#L105),\n> we can\n> [return an error](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/auth/authorization_checks.cpp#L90)\n> and avoid the more expensive `DocumentSource` parsing process.\n\nAfter confirming that the `LiteParsedPipeline` satisfies all the necessary permissions, the full\n`AggregateCommandRequest` is passed to\n[`Pipeline::parseCommon()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L213)\nas a vector of pipeline stages (represented as raw `BSONObj`s). Each pipeline stage is then\nre-parsed using\n[`DocumentSource::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.cpp#L101),\nwhich calls on the `DocumentSource::createFromBson()` parser for each stage. At the time of\nthis writing, this double parse happens for all stages, but\n[SPM-4362](https://jira.mongodb.org/browse/SPM-4362) is aiming to make it possible to 'upgrade' a\n`LiteParsedPipeline` to a full `Pipeline` without re-parsing from raw BSON. We will prototype this\ncapability but not replace all existing stage's parsing implementations. This will be important for\nextensions processing though - it's a step towards a world where full parsing and query shape\ngeneration happen earlier in the process.\n\n> ### Aside: `DocumentSource`\n>\n> A `DocumentSource` represents one stage of an aggregation pipeline. Each `DocumentSource` lives in\n> its own file with this form:\n> [`src/mongo/db/pipeline/document_source_`](https://github.com/mongodb/mongo/tree/master/src/mongo/db/pipeline),\n> with a\n> [`REGISTER_DOCUMENT_SOURCE`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.h#L99)\n> macro at the top. Each `DocumentSource` also features a `createFromBson()` function; this is the\n> main parsing function for each `DocumentSource`. By registering each document source with its lite\n> parsing and full parsing functions, we can recursively parse the entire pipeline, stage by stage.\n>\n> Not all `DocumentSource`s get parsed into their own stages. Major stages like `$match` do have a\n> [`createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_match.cpp#L594)\n> that returns a `DocumentSourceMatch`, but some stages are aliases for other `DocumentSource`s.\n>\n> - For example,\n> [`DocumentSourceBucket::createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_bucket.cpp#L74)\n> returns two `DocumentSource`s: a `$group` stage and a `$sort` stage by calling on\n> `DocumentSourceGroup` and `DocumentSourceSort`'s respective `createFromBson()` functions.\n\nThe\n[result](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L233)\nof this parsing is a\n[`Pipeline`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.h#L110)\nobject that contains a list of parsed `DocumentSource`s as a member. Our final goal, however, is to\nget a `CanonicalQuery`. This may or may not be possible depending on the type of aggregation. For\nexample:\n\n> ```\n> // This query fully undergoes optimization as a CanonicalQuery.\n> db.c.aggregate([{$match: {a: {$gte: 2, $lte: 10}}}, {$sort: {a: 1}}, {$limit: 5}])\n> // This query is not canonicalizable.\n> db.c.aggregate([{$addFields: {b: {$add: [\"$a\", 1]}}}])\n> ```\n\nIf some component of the `Pipeline` can become a `CanonicalQuery` (i.e. it contains a filter, sort,\nprojection, etc.), we will\n[create a `CanonicalQuery`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline_d.cpp#L1144)\nfor this `Pipeline`, and proceed with optimization and execution as we would with a find command.\n\n#### Parsing MapReduce\n\nAfter parsing into a `MapReduceCommandRequest` via IDL, the `MapReduceCommandRequest` is\n[translated](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/map_reduce_agg.cpp#L187)\ninto an equivalent pipeline using the same `DocumentSource` parsing functions as aggregation.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s2[\" \"]\n n4[\"Aggregate\"]\n n5[\"MapReduce\"]\n end\n n4 --> n21[\"IDL Parsing\"]\n n5 --> n21\n n21 --> n22[\"AggregateCommandRequest\"] & n30[\"MapReduceCommandRequest\"]\n n22 --> n23[\"LiteParsedPipeline\"]\n n23 -- Authorization Checks --> n22\n n28[\"Pipeline\"] --> n32[\"Is some component of the Pipeline canonicalizable?\"]\n n32 -- No --> n33>\"DocumentSourceExecution\"]\n n22 -- Pipeline::parseCommon()
DocumentSource::parse() --> n31[\"DocumentSources\"]\n n30 --> n31\n n31 -- \"DocumentSource<Stage>::createFromBson()\" --> n28\n n32 -- \"Yes
createCanonicalQuery()\" --> n17[\"CanonicalQuery\"]\n\n n21@{ shape: extract}\n n32@{ shape: diam}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Write Queries\n\nInsert, Delete, Update, and FindAndModify are all parsed by IDL as described above and converted\ninto a `BulkWriteCommandRequest`, `DeleteRequest`, `UpdateRequest`, `FindAndModifyCommandRequest`,\nrespectively.\n\nInserts are internally\n[represented](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/bulk_write.idl#L324)\nas a `BulkWriteCommandRequest` which contains an array of `BulkWriteInsertOp`s. No query\noptimization is needed for inserts beyond parsing, since insert is a write-only operation.\n\n`DeleteRequest`s are passed to `parsed_delete_command::parse()`, which parses them into\n`ParsedDelete` objects. `parsed_delete_command::parse()` uses `parseWriteQueryToParsedFindCommand()`\nto parse the `filter` component of the write query. This shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedDelete`. Subsequently, the `ParsedDelete` objects are passed to `CanonicalDelete::make()`,\nwhich constructs a `CanonicalDelete` consisting of a `CanonicalQuery`.\n\n`UpdateRequest`s are passed to `parsed_update_command::parse()`, which parses them into\n`ParsedUpdate` objects. `parsed_update_command::parse()` uses\n`parseWriteQueryToParsedFindCommand()`, which shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedUpdate`. Subsequently, the `ParsedUpdate` objects are passed to `CanonicalUpdate::make()`,\nwhich constructs a `CanonicalUpdate` consisting of a `CanonicalQuery`.\n\n`FindAndModifyCommandRequest`s can contain both find and update/delete syntax. For this reason, the\nquery portion is entirely delegated to the `find` query parser. The update or delete portion is\ntranslated into a `CanonicalUpdate` or `CanonicalDelete`, each of which uses the corresponding\ncodepath henceforth.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s3[\" \"]\n n6[\"Insert\"]\n n7[\"Delete\"]\n n8[\"Update\"]\n n9[\"FindAndModify\"]\n end\n n6 --> n31[\"IDL Parsing\"]\n n7 --> n31\n n8 --> n31\n n9 --> n31\n n31 --> n32[\"BulkWriteCommandRequest\"] & n34[\"DeleteRequest\"] & n35[\"UpdateRequest\"] & n39[\"FindAndModifyCommandRequest\"]\n n32 --o n33[\"BulkWriteInsertOp\"]\n n34 -- \"parsed_delete_command::parse()\" --> n36[\"ParsedDelete\"]\n n35 -- \"parsed_update_command::parse()\" --> n37[\"ParsedUpdate\"]\n n39 --> n36\n n39 --> n37\n n36 -- \"CanonicalDelete::make()\" --> n40[\"CanonicalDelete\"]\n n37 -- \"CanonicalUpdate::make()\" --> n41[\"CanonicalUpdate\"]\n n40 --o n17[\"CanonicalQuery\"]\n n41 --o n17\n\n n17@{ shape: dbl-circ}\n n31@{ shape: extract}\n```\n\n---\n\n[Return to Cover Page](../../query/README_QO.md)\n","isInternal":false,"tokens":5359,"sizeBytes":19989},{"name":"SCRIPTING_PROFILER_README.md","path":"src/mongo/db/commands/SCRIPTING_PROFILER_README.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/mongo/db/commands/SCRIPTING_PROFILER_README.md","title":"Command: /scripting_profiler_readme","category":"command-prompt","format":"markdown","content":"# Scripting Profiler\n\n## Prerequisite\n\nThis is one time setup for a host.\n\n```bash\n# This cmd is for ubuntu20, different os may need different cmd. AWS (evergreen host) may require addition pkg.\nsudo apt install linux-tools-generic\n# Make sure `perf` command runs well, and /usr/bin/perf exists.\n```\n\nRun following commands to allow `perf` runs without root permission:\n\n```bash\nsudo sysctl -w kernel.perf_event_paranoid=1\nsudo sysctl -w kernel.kptr_restrict=0\n# This makes the change persistant across reboots\nsudo echo \"kernel.perf_event_paranoid=1\\nkernel.kptr_restrict=0\" > /etc/sysctl.d/perf.conf\n```\n\n## How to use\n\n### Start the profiler\n\nSyntax\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n filename: ,\n mode: \n }\n)\n```\n\nParameters\n\n- filename: The output file of linux-perf without suffix\n - type: `string`\n - default value: `perf`\n- mode: The profiling mode\n - type: `string`\n - possible values: `record` or `counters`\n - default value: `record`\n\nResponse\n\n```\n{ pid: , ok: 1 }\n```\n\n### Stop the profiler\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n pid: \n }\n)\n```\n\nParameters:\n\n- pid: This is the perf process pid, it is returned when profiler is started.\n - type: `integer`\n - required: `true`\n\n## Example\n\n```bash\n# Start the profiler.\nlet pid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_sbe\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler, and generate profiling data.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n# Change some settings (e.g. using classic engine).\ndb.adminCommand({setParameter: 1, internalQueryFrameworkControl: \"forceClassicEngine\"})\n# Start profiler again with a different file name.\npid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_classic\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n## Using Shell\nperf report -i /home/ubuntu/tmp/perf_sbe.data\nperf report -i /home/ubuntu/tmp/perf_classic.data\n# Or generate flame graph\n```\n","isInternal":false,"tokens":606,"sizeBytes":2172},{"name":"wt-build.md","path":"src/third_party/wiredtiger/.claude/agents/wt-build.md","rawUrl":"https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/third_party/wiredtiger/.claude/agents/wt-build.md","title":"wt-build","category":"subagent-persona","format":"markdown","content":"---\nname: wt-build\ndescription: Use this agent when WiredTiger C/C++ source or test code has changed and the CMake build needs verification. Typical triggers include verifying a fresh edit compiles before running tests, a pre-commit sanity check after touching files under `src/` or `test/` (Catch2, csuite, cppsuite, format, etc.), and confirming a newly added source or test file is wired into the build.\ntools: [\"Bash\", \"Read\", \"Glob\", \"Grep\"]\nmodel: haiku\ncolor: yellow\n---\n\nYou are a build runner for WiredTiger. Compile the code with CMake and report the result. Be terse.\n\n## Procedure\n\n1. **Configure if needed.** If `build/CMakeCache.txt` exists, skip — respect the caller's existing configuration. Otherwise:\n ```\n cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug\n ```\n Default to `-DCMAKE_BUILD_TYPE=Debug` unless the caller specifies a different build type. Drop `-G Ninja` if `ninja` is not installed. Do not add other `-D` flags unless the caller asks; team members configure their own builds.\n\n2. **Pick a target.** If the caller named a CMake target, use it. Otherwise build everything.\n\n3. **Build**, redirecting output to a log file. The unfiltered output is large — never let it stream into your context:\n ```\n cmake --build build --parallel --target > build/last-build.log 2>&1\n ```\n Omit `--target ` for the fallback case. Report which target you built (or `all`) in the success/failure output so the caller can verify the scope.\n\n4. **Report.** On success, emit `SUCCESS` plus the target built and the last line of the log. On failure, emit `FAILED` plus the target and `file:line` for each error pulled from `build/last-build.log`. Use a grep that covers both GNU and macOS linker output:\n ```\n grep -E \"error:|undefined reference|Undefined symbols|ld: symbol|No such file|fatal error\" build/last-build.log | head -20\n ```\n\n## Edge cases\n\n- **Stale build directory.** If configure succeeds but the build fails with errors that look like missing files the caller just deleted (e.g. `No such file or directory` on a removed source), suggest the caller re-run `cmake -B build -G Ninja` or wipe `build/` — do not delete it yourself.\n- **Interrupted build.** If `cmake --build` exits non-zero with no errors in the log (e.g. SIGINT), report `FAILED — build interrupted, no errors logged` rather than inventing errors.\n- **Configure failure.** If the initial `cmake -B build` fails, report `FAILED` with the cmake error and stop; do not attempt to build.\n\n## Output format\n\n**On success:**\n```\nSUCCESS (target: ) — \n```\n\n**On failure:**\n```\nFAILED (target: )\n\nErrors:\n src/foo.c:123: error: 'bar' undeclared\n src/baz.c:45: error: ...\n\nLog: build/last-build.log\n```\n","frontmatter":{"name":"wt-build","description":"Use this agent when WiredTiger C/C++ source or test code has changed and the CMake build needs verification. Typical triggers include verifying a fresh edit compiles before running tests, a pre-commit sanity check after touching files under `src/` or `test/` (Catch2, csuite, cppsuite, format, etc.), and confirming a newly added source or test file is wired into the build.","tools":["Bash","Read","Glob","Grep"],"model":"haiku","color":"yellow"},"isInternal":false,"tokens":714,"sizeBytes":2785},{"name":".cursorrules","path":".cursorrules (nodejs-mongodb-cursorrules-prompt-file-tutorial.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/nodejs-mongodb-cursorrules-prompt-file-tutorial.mdc","title":"Awesome Cursorrules: nodejs mongodb tutorial","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for Node.js development with MongoDB integration.\"\nglobs: **/*\nalwaysApply: false\n---\nTech Stack:\n\nBackend: Node.js with Express.js\n\nDatabase: MongoDB with Mongoose ODM\n\nFrontend: React.js (for admin panel, if required)\n\nAuthentication: JSON Web Tokens (JWT)\n\nVersion Control: Git\n\nDeployment: Docker (optional)\n\nPrecision in User Requirements:\n\nStrictly adhere to specified user flow and game rules.\n\nStrategy: \n\nSummarize the pick submission process and outline the API endpoint and business logic in pseudocode before coding.\n\nStrategic Planning with Pseudocode:\n\nBegin each feature with detailed pseudocode.\n\nExample: Provide pseudocode for the weekly scoring process, detailing steps from game result input to entry status updates.\n\nCode Quality:\n\nEnsure secure, efficient code following RESTful API best practices.\n\nImplement proper error handling and input validation.\n\nUser Flow:\n\nUsers browse available Pools\n\nSubmit up to 3 Requests per Pool\n\nComplete payment for Requests\n\nAdmin approves/rejects Requests\n\nApproved Requests become Entries\n\nEntry Management:\n\nEach user can have up to 3 Entries per Pool\n\nEntries are numbered 1, 2, 3\n\nPicks are made and tracked separately for each Entry\n\nPick Management:\n\nUsers make Picks for each Entry separately\n\nPicks can be updated until deadline (game start or 1PM Sunday of the current week of the pick)\n\nScoring and Ranking:\n\nPicks scored after games complete\n\nWin: Entry moves to next week\n\nLoss: Entry eliminated from Pool\n\nEach Entry ranked separately in Pool standings\n\nResults and Standings:\n\nUsers view Picks/scores for each Entry separately\n\nPool standings show all Entries (multiple per User possible)\n\nPool members can view all Picks after scoring\n\nKey Implementation Points:\n\nLimit Requests to 3 per User per Pool\n\nTrack Requests and Entries separately (numbered 1, 2, 3)\n\nImplement payment status tracking in Request model\n\nCreate Entry only after admin approval and payment completion\n\nAdmin interface for managing and approving Requests\n\nImplement state transitions (Request: pending -> approved -> Entry created)\n","tokens":425,"sizeBytes":2111}],"systemPromptSnippet":"\n\n## JavaScript Test Code Conventions\n\n### Assertion Library\n\nALWAYS use our own assertion library that is defined at `src/mongo/shell/assert.js` and\nautomatically loaded into the global scope before running each test.\n\nALWAYS wrap commands with `assert.commandWorked()`, unless failures are expected and checked. Use\n`assert.writeOK()` when working with legacy bulk write APIs.\n\nUse `assert.soon()` only for asynchronous or eventually-consistent conditions.\n\n### Mocha Style for New Test Files\n\nUse the mocha style to structure test cases in newly added test files. The\n`jstests/libs/mochalite.js` module implements `describe`, `it`, `before`, `beforeEach`, `afterEach`,\nand `after`. Import only what you need. Feel free to add other mocha helper functions to\n`jstests/libs/mochalite.js` if they would make the current test cleaner.\n\n```js\nimport {before, describe, it} from \"jstests/libs/mochalite.js\";\n\ndescribe(\"feature under test\", function () {\n before(function () {\n /* one-time setup */\n });\n it(\"does X\", function () {\n /* ... */\n });\n});\n```\n\n### Use JSON-Conformant Object Serialization in Logs\n\nPass objects to the `attr` parameter of assertion and logging functions instead of concatenating\n`tojson()` into the message string. Most `assert.*` functions accept an `attr` object as their last\nargument.\n\n```js\n// Bad — tojson() in the message string\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing: \" + tojson(cursor));\n\n// Good — object passed via attr\nassert(cursor.hasOwnProperty(\"metrics\"), \"metrics missing\", {cursor});\n```\n\nFor logging:\n\n```js\n// Bad\njsTest.log.info(\"got cursor: \" + tojson(cursor));\n\n// Good\njsTest.log.info(\"got cursor\", {cursor});\n```\n\n### Resource and Settings Cleanup\n\nALWAYS clean up resources and settings immediately after they are no longer needed. Examples of\nserver resources are cursors and collections. Examples of settings are server parameters and test\nframework settings stored in the global `TestData` object.\n\n\n# Copilot instructions for this repository\n\n## Flag likely CVE / security-vulnerability fixes\n\nCommits on `master` are automatically synced to the public `mongodb/mongo` repository. A security\nfix that lands on `master` before the corresponding CVE is disclosed publicly reveals the\nvulnerability while released versions are still unpatched.\n\nWhen reviewing a pull request, flag it prominently if it looks like a fix for a security\nvulnerability or CVE. Signals include:\n\n- The PR, commit message, or linked ticket mentions a CVE, \"vulnerability\", \"security fix\",\n \"embargo\", or a security-team ticket.\n- The change fixes spoofing, forgery, injection, authentication/authorization bypass, privilege\n escalation, out-of-bounds access, or similar exploitable behavior.\n- The change hardens a trust boundary (e.g. validating previously trusted input from the network, a\n proxy header, or another node) or corrects audit-log attribution.\n- Documentation changes that describe how existing behavior can be abused by an attacker.\n\nIf any of these apply, add a review comment telling the author:\n\n> This PR looks like it may fix a security vulnerability. Because `master` is synced to the public\n> repository, this change must only be merged after the corresponding CVE has been publicly\n> disclosed and fixed releases are available. Confirm disclosure timing with the security team\n> before merging.\n\nDo not speculate about exploit details in review comments; just flag the disclosure-timing concern.\n\n\n# Extensions\n\nThis module provides utilities for setting up and configuring MongoDB extensions in resmoke test\nsuites.\n\n## Overview\n\nExtensions are dynamically loaded shared objects (`.so` files) that provide additional functionality\nto MongoDB. The utilities in this folder can handle:\n\n1. Discovering extension `.so` files in build directories\n2. Generating `.conf` configuration files for extensions\n3. Cleaning up configuration files after tests\n\n## Configuration File Generation in Tests\n\nExtension `.conf` files are YAML configuration files that tell the server how to load an extension.\nThey contain:\n\n- `sharedLibraryPath`: Path to the `.so` file\n- `extensionOptions`: Optional configuration parameters for the extension\n\nFor example:\n\n```yaml\n# foo.conf\nsharedLibraryPath: /path/to/libfoo_mongo_extension.so\nextensionOptions:\n someSetting: \n```\n\n### How Config Files Are Generated\n\nThe `generate_extension_configs.py` module creates `.conf` files:\n\n1. Receives a list of `.so` file paths (either from automatic discovery via\n `find_and_generate_extension_configs.py`, or manually via `--so-files` command-line argument)\n2. For each `.so`, creates a `.conf` file in the temp directory (`/tmp/mongo/extensions/`)\n3. Looks up corresponding extension options from\n `src/mongo/db/extension/test_examples/configurations.yml`, if any are specified\n4. Writes the config file with `sharedLibraryPath` and any `extensionOptions`\n\n### Automatic Discovery and Generation\n\nThe `find_and_generate_extension_configs.py` module combines discovery and generation:\n\n1. Searches for `*_mongo_extension.so` files in build directories:\n - **Evergreen:** `dist-test/lib/`\n - **Local:** `bazel-bin/install-dist-test/lib/` or `bazel-bin/install-extensions/lib/`\n2. Generates `.conf` files with a unique UUID suffix to avoid collisions\n3. Adds the `loadExtensions` parameter to mongod/mongos options\n\n\n# MongoDB Custom Clang Tidy module\n\nThe MongoDB server includes a custom clang-tidy module which allows server developers to write\ncustom clang-tidy rules for enforcement of best practices, finding bugs, and\n[large scale refactoring](https://www.youtube.com/watch?v=UfLH7dORav8). Checks for these rules will\nbe run as part of the commit queue and locally with the\n[clang-tidy vscode plugin](https://wiki.corp.mongodb.com/display/HGTC/Remote+Development+with+Visual+Studio+Code+%28vscode%29+for+MongoDB)\nor the clang-tidy command line.\n\nClang-tidy allows precise analysis of the code via the AST it builds internally. Our custom checks\nare employed through the use of a dynamic library which is loaded via the -load argument to\nclang-tidy. SDP and other teams plan to implement mongodb customized checks. If you are interested\nin implementing checks that can help enforce our standards in the codebase (or even just certain\ncomponents in the codebase), please reach out for more info.\n\nThe basics of implementing a check are in the\n[clang docs](https://releases.llvm.org/12.0.1/tools/clang/tools/extra/docs/clang-tidy/Contributing.html).\nIf you are planning to implement additional checks, it is highly recommended to look at the\n[existing clang tidy checks](https://github.com/llvm/llvm-project/tree/llvmorg-12.0.1/clang-tools-extra/clang-tidy)\nas reference starting material. Note that we use v4 toolchain with clang 12.0.1 and the clang tidy\ncheck API is subject to change between clang tidy versions. Also note that clang-tidy 12.0.1 release\ndoes not include the ability to load a module. This feature was backported into our v4 toolchain\nclang-tidy.\n\n#### Basic usage of the custom checks\n\nThe current directory contains the individual check source files, the main `MongoTidyModule.cpp`\nsource file which registers the checks, and the BUILD.bazel file responsible for building the check\nlibrary module. To build the custom checks use this command:\n\nThe bazel clang-tidy config will automatically build and use the custom checks module. To run clang\ntidy with the checks module use:\n\n bazel build --config=clang-tidy //src/mongo/...\n\n#### Adding check unittests\n\nA simple unittest framework is included with the checks so that they will automatically be run in\nquick, isolated, and minimal fashion. This allows for faster development and ensures the checks\ncontinue working.\n\nThe `test` directory contains the python unittest script, the test source files, and the BUILD.bazel\nwhich builds and runs the tests. To run all the custom tidy rules unittests use:\n\n bazel run mongo-tidy-test\n\nThis will run all the tests serially. Eventually we can improve this and they can be run in parallel\nbut currently they are serial. To run a specific test you can use python's unittest args, for\nexample:\n\nbazel run mongo-tidy-test -- -k test_MongoInvariantStatusIsOKCheck\n\n#### Writing your own check checklist\n\nBelow is a checklist of all the steps to make sure to perform when writing a new check.\n\n1. Implement the check in the respectively named `.h` and `.cpp` files.\n2. Add the check's `#include` to the `MongoTidyModule.cpp`.\n3. Register the check class with a check name in the `MongoTidyModule.cpp`.\n4. Add the `.cpp` file to the source list in the `BUILD.bazel` file.\n5. Write a unittest file named `tests/test_{CHECK_NAME}.cpp` and a config file\n `tests/test_{CHECK_NAME}.tidy_config` which minimally reproduces the issue.\n6. Add the test to the list of tests in `tests/BUILD.bazel`.\n7. Add a `def test_{CHECK_NAME}():` function to the `MongoTidyCheck_unittest.py` file which finds\n the expected error output in the stdout. Reference the other check functions for details.\n8. Run the bazel build with `bazel run mongo-tidy-test -- -k test_{CHECK_NAME}` to run the newly\n created test.\n\n#### Questions and Troubleshooting\n\nIf you have any questions please reach out to the `#ask-devprod-build` slack channel.\n\n\n# Workload Simulation\n\nThis directory provides code for generating `*_simulator` executables that test various components\nof the system under a simulated workload. The executables produces log output that can be converted\ninto graphs plotting metrics collected over time using `process_logs.py`.\n\nThe simulations themselves are carried out using an event queue and a mock clock. Workload drivers\nspawn and manage actor threads that are responsible for sending _event_ requests to the queue, where\neach request is tied to a time. The queue is responsible for advancing the clock appropriately and\nnotifying the actor threads when the clock has reached the appropriate time for their requests to be\nprocessed. Additional, non-actor threads can similarly wait for specific times during the simulation\nby registering _observer_ requests that are maintained in a separate internal queue.\n\nMore specifically:\n\n1. The event queue waits until it has received an _event_ request from each reported actor thread.\n2. When it is sufficiently full, the queue determines the minimum time of a queued _event_ request,\n and advances the mock clock to that time.\n3. The queue then notifies any threads waiting on either _event_ or _observer_ requests at or before\n the current time.\n\nThe _observer_ mechanism is used to trigger periodic metric reporting for the log output. It may\nalso be used by workload drivers to trigger periodic jobs.\n\n## Defining a Simulation\n\nThe [`simulation.h`](simulation.h) header defines a `SIMULATION` macro that functions similarly to\nthe `TEST_F` macro in our unittesting framework. It expects the first parameter to be the name of a\nfixture class derived from `mongo::workload_simulation::Simulation`. The second parameter is the\nname of the workload, and any additional parameters will be passed as input to the constructor of\nthe fixture class.\n\nA C++ file that defines these macros can be compiled using the `simulator_main` bazel target to link\nthe relevant `main` implementation that runs all the workloads defined using the macro.\n\n## Generating Visualizations\n\nA `*_simulator` executable simply runs all selected workloads and outputs logs to stdout. These logs\ncan be piped to `process_logs.py` to generate graphs. Ex.\n\n```\n$ throughput_probing_simulator | process_logs.py -o ~/sim_output\n```\n\n\n# Throughput Probing Simulations\n\nThis directory provides code for an executable `throughput_probing_simulator` that tests our\nthroughput probing algorithm used for execution control under a simulated workload. The workload\noutput consists of graphs showing the actual and optimal ticket allocations over time.\n\nThe rough workflow for an individual simulation is:\n\n1. Specify an optimal concurrency level, and the throughput at that concurrency level.\n2. Provide a well-behaved model for what throughput we will observe at different concurrency levels,\n and what operation latencies would produce that throughput.\n3. Use that model to specify a workload driver which simulates operations with the given latencies\n based on the current concurrency level selected by the throughput probing algorithm.\n4. Run the mock workload for specified duration.\n\n## File Structure\n\nNew workloads can be added in [`workloads.cpp`](workloads.cpp)\n\nThe existing `TicketedWorkloadDriver` is quite flexible, and should suffice for most workloads by\nsimply tuning the workload characteristics, runtime, etc. New workload characterstic types can be\ndefined in [`workload_characteristics.h`](../workload_characteristics.h).\n\n\nDon't make manual changes to files in the dist/ or platform/ directories.\nSource code changes should be made in the mongodb-labs/gperftools repo.\nTweaks or reconfigurations of our third-party installation have to be\nmade in scripts/ or BUILD.bazel files, etc.\n\n== contents ==\n\n```\n src/third_party/\n gperftool-2.7/\n dist/ # 'make distdir' snapshot of mongodb-labs/gperftools\n platform/\n linux_x86_64/ # per platform directories\n include/ # headers used by consumers of gperftools\n internal/ # headers used in the compile of gperftools\n ... # other platforms: $os_$arch\n windows_x86_64/ # special case that's always regenerated, and always the same way.\n scripts/\n import.sh # regenerate the dist/ snapshot from git repo.\n host_config.sh # generate platform headers dir for the host and windows_x86_64.\n```\n\n\n# rootAnalysis Documentation\n\nPath: `src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/mongodb/mongo/HEAD/src/third_party/mozjs/extract/js/src/devtools/rootAnalysis/README.md)\n\n\n# Parsing\n\n## Overview\n\nThe query system's parsing layer has two main components:\n\n1. [Command Parsing and Validation](#command-parsing-and-validation) is responsible for parsing the\n arguments to each command, verifying the expected number of arguments, and checking their types.\n1. [Query Language Parsing and Validation](#query-language-parsing-and-validation) is responsible\n for more query-specific parsing. This includes (but is not limited to) parsing query predicates\n and aggregation pipelines.\n\nOverall, the parsing layer translates from a client-facing command (e.g. find or aggregate) to a\nparsed command object (e.g. `ParsedFindCommand` or `Pipeline`). These parsed command objects are\nthen normalized to form the input of query planning: `CanonicalQuery`,\n[if possible](#parsing-aggregations).\n\n> ### Aside: `CanonicalQuery`\n>\n> A\n> [`CanonicalQuery`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/query/canonical_query.h#L72)\n> is a container that represents a parsed and normalized query. This includes features such as the\n> query's `filter`, `projection`, and `sort` elements. See\n> [here](../../query/README_logical_models.md#canonicalquery) for more information regarding\n> `CanonicalQuery` and its normalization.\n\n## Command Parsing and Validation\n\nThe QO team maintains the following commands:\n\n- Category 1: Basic Read Queries\n - `find`\n - `distinct`\n - `count`\n- Category 2: Aggregations\n - `aggregate`\n - `mapReduce`\n - Note: `mapReduce` was deprecated in MongoDB v5.0 in favor of standard aggregation.\n- Category 3: Write Queries\n - `insert`\n - `delete`\n - `update`\n - `findAndModify`\n\nEach command starts in a class that inherits from the\n[`Command`](https://github.com/mongodb/mongo/blob/5342b2bab6a7ff264f21a44cc8b8310d6fc7bc01/src/mongo/db/commands.h#L436)\nabstract class. These commands all live in the [`src/mongo/db/commands/`](/src/mongo/db/commands)\ndirectory. For example:\n\n- `FindCmd` lives in [find_cmd.cpp](/src/mongo/db/commands/query_cmd/find_cmd.cpp)\n- `aggregate`'s command (`AggregateCommand`) lives in\n [`aggregate_command.cpp`](/src/mongo/db/commands/query_cmd/aggregate_command.cpp).\n\nFirst, we piece apart the command into its components. We don't yet try to understand the meaning of\nthe more complex MQL arguments, such as find's `filter`, `projection`, and `sort` arguments, or the\nindividual stages in `aggregate`'s `pipeline` argument.\n\n> ### Aside: Command Parsing vs. Query Parsing\n>\n> The overall parsing layer reflects this hierarchy:\n>\n> 1. A valid bytestring may contain a possibly valid `BSON`, extracted using a **BSON parser**.\n> 1. A valid `BSON` may contain a possibly valid **command**, extracted using a\n> [**command parser**](#aside-the-interface-definition-language).\n> 1. A valid command may contain a possibly valid **query**, extracted using an\n> [**MQL parser**](#query-language-parsing-and-validation).\n>\n> At this point, we are considering the second layer, from `BSON` to `Command`.\n\nFor example, given this find query:\n\n```\ndb.c.find({$or: [{a: {$lt: 2}}, {a: 6}]}).sort({a: 1}).limit(5);\n```\n\nwe generate a C++ struct that stores `filter`, `sort`, and `limit` as member variables. Note that\n`filter` is left as a `BSONObj`; we don't yet \"know\" that it contains a `$or`. Rather than manually\nwriting the conversion code, we use an **Interface Definition Language** (IDL) tool to generate the\nparser and output a corresponding C++ struct. In the `find` case, `find_command.idl` generates\n`find_command_gen.h` and `find_command_gen.cpp` and by extension, a `FindCommandRequestBase` struct.\n\n> ### Aside: The Interface Definition Language\n>\n> Below is a simplified snippet of the relevant portion of `find_command.idl`. The full file can be\n> viewed [here](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/find_command.idl).\n>\n> ```yaml\n> commands:\n> find:\n> cpp_name: FindCommandRequestBase\n> command_name: find\n> description: \"A struct representing the find command\"\n> fields:\n> filter:\n> description: \"The query predicate. If unspecified, then all documents in the collection\n> will match the predicate.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> sort:\n> description: \"The sort specification for the ordering of the results.\"\n> type: object\n> default: mongo::BSONObj()\n> stability: stable\n> limit:\n> description: \"The maximum number of documents to return.\"\n> type: safeInt64\n> optional: true\n> validator: { gte: 0 }\n> stability: stable\n> ```\n>\n> This file (specified in a YAML format) is used to generate C++ code that will in turn create a\n> `FindCommandRequestBase`. Our build system will run a python tool to parse this YAML and spit out\n> C++ code which is then compiled and linked. This code is left in a file ending with '\\_gen.h' or\n> '\\_gen.cpp' (here `find_command_gen.cpp`). The YAML includes specifications of each field, such as\n> its type, whether it is optional, and any default values. The generated file will have getter and\n> setter member functions and will return a `boost::optional` for optional fields. Now, we have a\n> `FindCommandRequestBase` struct that neatly contains C++ members for each of the components of our\n> query.\n\n### Additional Setup Before MQL Processing\n\n#### `ExpressionContext`\n\nAn\n[**`ExpressionContext`**](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/pipeline/expression_context.h#L132)\nstores various pieces of state and settings that are pertinent throughout the lifespan of a query\nbut are not necessarily relevant to other types of operations. This includes elements such as the\ncollation, a time zone database, and other configuration flags (feature flags, query knobs, etc.).\nEach command initializes its own `ExpressionContext`; our `find` example does so\n[here](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L191).\n\n#### Non-IDL Command Validation\n\nOccasionally, the IDL parsers will not be able to express certain command constraints. For example,\nthe `findAndModify` command cannot specify `true` for both `remove` and `new`, but the\n[IDL parser](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/write_ops/write_ops.idl#L533)\nalone cannot restrict the user from doing this. In these cases, we add a\n[`validate()`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_and_modify.cpp#L133)\nfunction to perform these final checks.\n\n## Query Language Parsing and Validation\n\n### Parsing Read Queries: Find, Distinct, and Count\n\n#### Parsing Find\n\nAs discussed above, the IDL handles creation of a `FindCommandRequest`. With this\n`FindCommandRequest` struct, we can now call\n[`parsed_find_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196),\npassing in the `ExpressionContext` and a new struct of type `ParsedFindCommandParams`, which\ncontains the `FindCommandRequest` as a member. A few function calls later, we reach\n[`MatchExpressionParser::parse()`](https://github.com/mongodb/mongo/blob/0a68308f0d39a928ed551f285ba72ca560c38576/src/mongo/db/query/parsed_find_command.cpp#L186)\nwhich recursively parses the `BSONObj` `filter` component of our `FindCommandRequest` by using the\n`parse()` function for each type of `MatchExpression` node. This AST structure assembles the\n`filter` in an easily optimizable format, as each subclass `MatchExpression` node knows which\nrewrites are possible given their place in the AST. For more information on `MatchExpression`s, see\n[Logical Models](../../query/README_logical_models.md).\n\nAfter parsing our `MatchExpression` into a tree of `MatchExpression`s , we pass the full\n`MatchExpression` AST to a `ParsedFindCommand`. Note that `ParsedFindCommand`s only primary\ncomponents are the `filter`, `projection`, and `sort`; all other parameters (e.g. `limit`, `skip`,\n`batchSize`, etc.) are held as raw types in the `FindCommandRequest`.\n\nFinally, we\n[create](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/commands/query_cmd/find_cmd.cpp#L196)\na `CanonicalQuery` by passing the `ParsedFindCommand` as an argument, thereby giving the\n`CanonicalQuery` the `filter`, `projection`, `sort`, and `FindCommandRequest`.\n\n#### Parsing Distinct and Count\n\nThe process of parsing `distinct` and `count` queries is nearly identical to that of `find`.\n\nDistinct queries are parsed by IDL into a `DistinctCommandRequest`, which is in turn converted into\na `ParsedDistinctCommand` by\n[`parsed_distinct_command::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_distinct_command.cpp#L132).\nIf a `filter` exists on the command, it is parsed using `MatchExpressionParser::parse()` like\n`find`. We then create a `CanonicalQuery` by an equivalent process to find, and\n[add a `CanonicalDistinct`](https://github.com/mongodb/mongo/blob/903127224b53dee29888d8e799e41cf747191fc0/src/mongo/db/query/parsed_distinct_command.cpp#L277)\nproperty to the `CanonicalQuery` with the details of the `distinct` query, such as its distinct key.\n\nCount queries are parsed using `ParsedFindCommand`'s\n[`parseFromCount()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/query/parsed_find_command.cpp#L346)\nfunction, which converts a `CountCommandRequest` into a `FindCommandRequest` and uses the same logic\nas `find` thereafter.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s1[\" \"]\n n1[\"Find\"]\n n2[\"Distinct\"]\n n3[\"Count\"]\n end\n n1 --> n10[\"IDL Parsing\"]\n n2 --> n10\n n3 --> n10\n n10 --> n11[\"FindCommandRequest\"] & n12[\"DistinctCommandRequest\"]\n n10 --> n21[\"CountCommandRequest\"]\n n13[\"ParsedFindCommand\"] --> n17[\"CanonicalQuery\"]\n n19[\"ParsedDistinctCommand\"] --> n17\n n21 -- parseFromCount() --> n11\n n11 -- \"parsed_find_command::parse()
MatchExpressionParser::parse()\" --> n13\n n12 -- \"parsed_distinct_command::parse()
MatchExpressionParser::parse()\" --> n19\n\n n10@{ shape: extract}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Aggregations\n\nAfter producing an `AggregateCommandRequest` via IDL, the request is\n[passed and parsed](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_pipeline.h#L70)\ninto a `LiteParsedPipeline`.\n\n> ### Aside: `LiteParsedPipeline`\n>\n> A `LiteParsedPipeline` is a simple model of an aggregation pipeline that is constructed through a\n> [semi-parse](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/lite_parsed_document_source.h#L145)\n> that proceeds just enough to tease apart the stages that are involved. `LiteParsedPipeline`s do\n> not verify that the input is well-formed; instead, they can be used to _inspect_ queries before\n> building a full model of the user's pipeline.\n>\n> - For example, on systems running with authorization, the `$currentOp` aggregation stage requires\n> that the user has access that includes the\n> [`inprog`](https://www.mongodb.com/docs/manual/reference/privilege-actions/#mongodb-authaction-inprog)\n> privilege action. That means that if our `LiteParsedPipeline` finds a `$currentOp` that does not\n> satisfy the\n> [necessary privileges](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_current_op.h#L105),\n> we can\n> [return an error](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/auth/authorization_checks.cpp#L90)\n> and avoid the more expensive `DocumentSource` parsing process.\n\nAfter confirming that the `LiteParsedPipeline` satisfies all the necessary permissions, the full\n`AggregateCommandRequest` is passed to\n[`Pipeline::parseCommon()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L213)\nas a vector of pipeline stages (represented as raw `BSONObj`s). Each pipeline stage is then\nre-parsed using\n[`DocumentSource::parse()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.cpp#L101),\nwhich calls on the `DocumentSource::createFromBson()` parser for each stage. At the time of\nthis writing, this double parse happens for all stages, but\n[SPM-4362](https://jira.mongodb.org/browse/SPM-4362) is aiming to make it possible to 'upgrade' a\n`LiteParsedPipeline` to a full `Pipeline` without re-parsing from raw BSON. We will prototype this\ncapability but not replace all existing stage's parsing implementations. This will be important for\nextensions processing though - it's a step towards a world where full parsing and query shape\ngeneration happen earlier in the process.\n\n> ### Aside: `DocumentSource`\n>\n> A `DocumentSource` represents one stage of an aggregation pipeline. Each `DocumentSource` lives in\n> its own file with this form:\n> [`src/mongo/db/pipeline/document_source_`](https://github.com/mongodb/mongo/tree/master/src/mongo/db/pipeline),\n> with a\n> [`REGISTER_DOCUMENT_SOURCE`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source.h#L99)\n> macro at the top. Each `DocumentSource` also features a `createFromBson()` function; this is the\n> main parsing function for each `DocumentSource`. By registering each document source with its lite\n> parsing and full parsing functions, we can recursively parse the entire pipeline, stage by stage.\n>\n> Not all `DocumentSource`s get parsed into their own stages. Major stages like `$match` do have a\n> [`createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_match.cpp#L594)\n> that returns a `DocumentSourceMatch`, but some stages are aliases for other `DocumentSource`s.\n>\n> - For example,\n> [`DocumentSourceBucket::createFromBson()`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/document_source_bucket.cpp#L74)\n> returns two `DocumentSource`s: a `$group` stage and a `$sort` stage by calling on\n> `DocumentSourceGroup` and `DocumentSourceSort`'s respective `createFromBson()` functions.\n\nThe\n[result](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.cpp#L233)\nof this parsing is a\n[`Pipeline`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline.h#L110)\nobject that contains a list of parsed `DocumentSource`s as a member. Our final goal, however, is to\nget a `CanonicalQuery`. This may or may not be possible depending on the type of aggregation. For\nexample:\n\n> ```\n> // This query fully undergoes optimization as a CanonicalQuery.\n> db.c.aggregate([{$match: {a: {$gte: 2, $lte: 10}}}, {$sort: {a: 1}}, {$limit: 5}])\n> // This query is not canonicalizable.\n> db.c.aggregate([{$addFields: {b: {$add: [\"$a\", 1]}}}])\n> ```\n\nIf some component of the `Pipeline` can become a `CanonicalQuery` (i.e. it contains a filter, sort,\nprojection, etc.), we will\n[create a `CanonicalQuery`](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/pipeline/pipeline_d.cpp#L1144)\nfor this `Pipeline`, and proceed with optimization and execution as we would with a find command.\n\n#### Parsing MapReduce\n\nAfter parsing into a `MapReduceCommandRequest` via IDL, the `MapReduceCommandRequest` is\n[translated](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/map_reduce_agg.cpp#L187)\ninto an equivalent pipeline using the same `DocumentSource` parsing functions as aggregation.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s2[\" \"]\n n4[\"Aggregate\"]\n n5[\"MapReduce\"]\n end\n n4 --> n21[\"IDL Parsing\"]\n n5 --> n21\n n21 --> n22[\"AggregateCommandRequest\"] & n30[\"MapReduceCommandRequest\"]\n n22 --> n23[\"LiteParsedPipeline\"]\n n23 -- Authorization Checks --> n22\n n28[\"Pipeline\"] --> n32[\"Is some component of the Pipeline canonicalizable?\"]\n n32 -- No --> n33>\"DocumentSourceExecution\"]\n n22 -- Pipeline::parseCommon()
DocumentSource::parse() --> n31[\"DocumentSources\"]\n n30 --> n31\n n31 -- \"DocumentSource<Stage>::createFromBson()\" --> n28\n n32 -- \"Yes
createCanonicalQuery()\" --> n17[\"CanonicalQuery\"]\n\n n21@{ shape: extract}\n n32@{ shape: diam}\n n17@{ shape: dbl-circ}\n```\n\n### Parsing Write Queries\n\nInsert, Delete, Update, and FindAndModify are all parsed by IDL as described above and converted\ninto a `BulkWriteCommandRequest`, `DeleteRequest`, `UpdateRequest`, `FindAndModifyCommandRequest`,\nrespectively.\n\nInserts are internally\n[represented](https://github.com/mongodb/mongo/blob/65b9efd4861b9f0d61f8b29843d29febcba91bcb/src/mongo/db/commands/query_cmd/bulk_write.idl#L324)\nas a `BulkWriteCommandRequest` which contains an array of `BulkWriteInsertOp`s. No query\noptimization is needed for inserts beyond parsing, since insert is a write-only operation.\n\n`DeleteRequest`s are passed to `parsed_delete_command::parse()`, which parses them into\n`ParsedDelete` objects. `parsed_delete_command::parse()` uses `parseWriteQueryToParsedFindCommand()`\nto parse the `filter` component of the write query. This shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedDelete`. Subsequently, the `ParsedDelete` objects are passed to `CanonicalDelete::make()`,\nwhich constructs a `CanonicalDelete` consisting of a `CanonicalQuery`.\n\n`UpdateRequest`s are passed to `parsed_update_command::parse()`, which parses them into\n`ParsedUpdate` objects. `parsed_update_command::parse()` uses\n`parseWriteQueryToParsedFindCommand()`, which shares the same parsing flow as\n`parseWriteQueryToCQ()`. However, the difference is that it generates a pre-optimized\n`ParsedFindCommand`, allowing other components to access the pre-optimized parsed structure from\n`ParsedUpdate`. Subsequently, the `ParsedUpdate` objects are passed to `CanonicalUpdate::make()`,\nwhich constructs a `CanonicalUpdate` consisting of a `CanonicalQuery`.\n\n`FindAndModifyCommandRequest`s can contain both find and update/delete syntax. For this reason, the\nquery portion is entirely delegated to the `find` query parser. The update or delete portion is\ntranslated into a `CanonicalUpdate` or `CanonicalDelete`, each of which uses the corresponding\ncodepath henceforth.\n\n```mermaid\n---\nconfig:\n themeVariables:\n fontSize: 32px\n---\nflowchart LR\n subgraph s3[\" \"]\n n6[\"Insert\"]\n n7[\"Delete\"]\n n8[\"Update\"]\n n9[\"FindAndModify\"]\n end\n n6 --> n31[\"IDL Parsing\"]\n n7 --> n31\n n8 --> n31\n n9 --> n31\n n31 --> n32[\"BulkWriteCommandRequest\"] & n34[\"DeleteRequest\"] & n35[\"UpdateRequest\"] & n39[\"FindAndModifyCommandRequest\"]\n n32 --o n33[\"BulkWriteInsertOp\"]\n n34 -- \"parsed_delete_command::parse()\" --> n36[\"ParsedDelete\"]\n n35 -- \"parsed_update_command::parse()\" --> n37[\"ParsedUpdate\"]\n n39 --> n36\n n39 --> n37\n n36 -- \"CanonicalDelete::make()\" --> n40[\"CanonicalDelete\"]\n n37 -- \"CanonicalUpdate::make()\" --> n41[\"CanonicalUpdate\"]\n n40 --o n17[\"CanonicalQuery\"]\n n41 --o n17\n\n n17@{ shape: dbl-circ}\n n31@{ shape: extract}\n```\n\n---\n\n[Return to Cover Page](../../query/README_QO.md)\n\n\n# Scripting Profiler\n\n## Prerequisite\n\nThis is one time setup for a host.\n\n```bash\n# This cmd is for ubuntu20, different os may need different cmd. AWS (evergreen host) may require addition pkg.\nsudo apt install linux-tools-generic\n# Make sure `perf` command runs well, and /usr/bin/perf exists.\n```\n\nRun following commands to allow `perf` runs without root permission:\n\n```bash\nsudo sysctl -w kernel.perf_event_paranoid=1\nsudo sysctl -w kernel.kptr_restrict=0\n# This makes the change persistant across reboots\nsudo echo \"kernel.perf_event_paranoid=1\\nkernel.kptr_restrict=0\" > /etc/sysctl.d/perf.conf\n```\n\n## How to use\n\n### Start the profiler\n\nSyntax\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n filename: ,\n mode: \n }\n)\n```\n\nParameters\n\n- filename: The output file of linux-perf without suffix\n - type: `string`\n - default value: `perf`\n- mode: The profiling mode\n - type: `string`\n - possible values: `record` or `counters`\n - default value: `record`\n\nResponse\n\n```\n{ pid: , ok: 1 }\n```\n\n### Stop the profiler\n\n```\ndb.adminCommand(\n {\n sysprofile: 1,\n pid: \n }\n)\n```\n\nParameters:\n\n- pid: This is the perf process pid, it is returned when profiler is started.\n - type: `integer`\n - required: `true`\n\n## Example\n\n```bash\n# Start the profiler.\nlet pid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_sbe\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler, and generate profiling data.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n# Change some settings (e.g. using classic engine).\ndb.adminCommand({setParameter: 1, internalQueryFrameworkControl: \"forceClassicEngine\"})\n# Start profiler again with a different file name.\npid = db.adminCommand({sysprofile: 1, filename: \"/home/ubuntu/tmp/perf_classic\"}).pid;\n# Run some queries.\nfor (let i = 0; i < 1000; ++i) {\n db.search.find({}).toArray();\n}\n# Stop the profiler.\ndb.adminCommand({sysprofile: 1, pid: pid})\n\n## Using Shell\nperf report -i /home/ubuntu/tmp/perf_sbe.data\nperf report -i /home/ubuntu/tmp/perf_classic.data\n# Or generate flame graph\n```\n\n\n---\nname: wt-build\ndescription: Use this agent when WiredTiger C/C++ source or test code has changed and the CMake build needs verification. Typical triggers include verifying a fresh edit compiles before running tests, a pre-commit sanity check after touching files under `src/` or `test/` (Catch2, csuite, cppsuite, format, etc.), and confirming a newly added source or test file is wired into the build.\ntools: [\"Bash\", \"Read\", \"Glob\", \"Grep\"]\nmodel: haiku\ncolor: yellow\n---\n\nYou are a build runner for WiredTiger. Compile the code with CMake and report the result. Be terse.\n\n## Procedure\n\n1. **Configure if needed.** If `build/CMakeCache.txt` exists, skip — respect the caller's existing configuration. Otherwise:\n ```\n cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug\n ```\n Default to `-DCMAKE_BUILD_TYPE=Debug` unless the caller specifies a different build type. Drop `-G Ninja` if `ninja` is not installed. Do not add other `-D` flags unless the caller asks; team members configure their own builds.\n\n2. **Pick a target.** If the caller named a CMake target, use it. Otherwise build everything.\n\n3. **Build**, redirecting output to a log file. The unfiltered output is large — never let it stream into your context:\n ```\n cmake --build build --parallel --target > build/last-build.log 2>&1\n ```\n Omit `--target ` for the fallback case. Report which target you built (or `all`) in the success/failure output so the caller can verify the scope.\n\n4. **Report.** On success, emit `SUCCESS` plus the target built and the last line of the log. On failure, emit `FAILED` plus the target and `file:line` for each error pulled from `build/last-build.log`. Use a grep that covers both GNU and macOS linker output:\n ```\n grep -E \"error:|undefined reference|Undefined symbols|ld: symbol|No such file|fatal error\" build/last-build.log | head -20\n ```\n\n## Edge cases\n\n- **Stale build directory.** If configure succeeds but the build fails with errors that look like missing files the caller just deleted (e.g. `No such file or directory` on a removed source), suggest the caller re-run `cmake -B build -G Ninja` or wipe `build/` — do not delete it yourself.\n- **Interrupted build.** If `cmake --build` exits non-zero with no errors in the log (e.g. SIGINT), report `FAILED — build interrupted, no errors logged` rather than inventing errors.\n- **Configure failure.** If the initial `cmake -B build` fails, report `FAILED` with the cmake error and stop; do not attempt to build.\n\n## Output format\n\n**On success:**\n```\nSUCCESS (target: ) — \n```\n\n**On failure:**\n```\nFAILED (target: )\n\nErrors:\n src/foo.c:123: error: 'bar' undeclared\n src/baz.c:45: error: ...\n\nLog: build/last-build.log\n```\n\n\n---\ndescription: \"Cursor rules for Node.js development with MongoDB integration.\"\nglobs: **/*\nalwaysApply: false\n---\nTech Stack:\n\nBackend: Node.js with Express.js\n\nDatabase: MongoDB with Mongoose ODM\n\nFrontend: React.js (for admin panel, if required)\n\nAuthentication: JSON Web Tokens (JWT)\n\nVersion Control: Git\n\nDeployment: Docker (optional)\n\nPrecision in User Requirements:\n\nStrictly adhere to specified user flow and game rules.\n\nStrategy: \n\nSummarize the pick submission process and outline the API endpoint and business logic in pseudocode before coding.\n\nStrategic Planning with Pseudocode:\n\nBegin each feature with detailed pseudocode.\n\nExample: Provide pseudocode for the weekly scoring process, detailing steps from game result input to entry status updates.\n\nCode Quality:\n\nEnsure secure, efficient code following RESTful API best practices.\n\nImplement proper error handling and input validation.\n\nUser Flow:\n\nUsers browse available Pools\n\nSubmit up to 3 Requests per Pool\n\nComplete payment for Requests\n\nAdmin approves/rejects Requests\n\nApproved Requests become Entries\n\nEntry Management:\n\nEach user can have up to 3 Entries per Pool\n\nEntries are numbered 1, 2, 3\n\nPicks are made and tracked separately for each Entry\n\nPick Management:\n\nUsers make Picks for each Entry separately\n\nPicks can be updated until deadline (game start or 1PM Sunday of the current week of the pick)\n\nScoring and Ranking:\n\nPicks scored after games complete\n\nWin: Entry moves to next week\n\nLoss: Entry eliminated from Pool\n\nEach Entry ranked separately in Pool standings\n\nResults and Standings:\n\nUsers view Picks/scores for each Entry separately\n\nPool standings show all Entries (multiple per User possible)\n\nPool members can view all Picks after scoring\n\nKey Implementation Points:\n\nLimit Requests to 3 per User per Pool\n\nTrack Requests and Entries separately (numbered 1, 2, 3)\n\nImplement payment status tracking in Request model\n\nCreate Entry only after admin approval and payment completion\n\nAdmin interface for managing and approving Requests\n\nImplement state transitions (Request: pending -> approved -> Entry created)\n"}