• Merge any new commits in master into the issue branch, prior to testing (recommended best practice!)
• Run ARAX pytest suite, using the code in the issue branch
• Test your issue branch using the /deploy mechanism; verify Example queries work
• (Optional) arax.ncats.io integration test of the issue branch code, inside a devarea in the rtx2 container
  • (If you test in an rtx2 devarea): Switch arax.ncats.io devarea back to the branch it was previously on (often master)
• Open a PR for review
• Merge the issue branch into master
• Delete issue-XXX branch
• Note in ARAX changelog
• Note in CATRAX Year 2 milestones
• Add to ARAX AHM agenda
• Note in parent issue (e.g., on NCATSTranslator/Feedback, or ARAX parent issue), if applicable

This procedure is primarily intended for use by team members working on maintenance of the ARAX system.

So far as the author is aware, the x86_64 and ARM64 CPU architectures both work (but please do not try to run ARAX on Windows unless it is in WSL/WSL2 Linux). Your local development computer should have:

• 200 GiB of free disk space
• 32 GiB of memory
• python3.12 installed (with the venv, i.e., virtualenv, module available in it)
• Internet (access to the OSU address space via VPN is only required for certain steps late in the process)
• a mainstream web browser installed (Chrome/Firefox)
• tools that need to be installed, by Homebrew or apt or similar: bash, curl, OpenSSH, git, jq, yq
• VPN access to which ever IP block is registered with ITRB for access to arax.ncats.io

Further, you will need:

• write access to the ARAX GitHub project area (RTXteam/RTX.git)
• ssh access to arax-databases.rtx.ai as user ubuntu rtxconfig
• ssh access to araxconfig.rtx.ai as user araxconfig
• ssh access to arax.ncats.io
• ssh key installed on GitHub so you can clone and commit over ssh

If you are going to be deploying a new (or updated) database to ITRB CI, you will need ssh access to the ITRB sftp staging server: sftp [email protected] and to the CATRAX team's CI/CD server, [email protected].

It's also helpful to have basic network troubleshooting utilities like netstat, nc, etc., installed.

You only need to perform this "setup" procedure once; you don't need to do it each time you work on a new ARAX issue. You will, however, need to carry out this procedure after each major new release of ARAX databases.

1. You will need to get the following databases:

COHDdatabase_v1.0_KG2.8.0.db
ExplainableDTD
autocomplete
curie_ngd
curie_to_pmids
fda_approved_drugs_v1.0.pickle
tier0-info-for-overlay

On the server, each file name includes a version (e.g. v1.0) and a Tier0 build date (tier0-YYYYMMDD). Get the exact files listed under database_downloads in code/config_dbs.json on the branch you are testing. Don't take the newest files on the server. The path in that file tells you where each one lives on arax-databases.rtx.ai (under /home/rtxconfig/). For example, the team may have built new artifacts against a new graph release, but that graph release is not actually in CI yet.

Download these databases into a directory at the same level as the RTX repository (HOW-TO follows). Your dev directory (the one containing RTX) is called ARAX_DEV_DIR in this document. Inside it, create a DB_DIR (call it whatever you want; it's referenced as DB_DIR in this document). This directory should be persistent and able to be shared across all issues. Within the DB_DIR directory, create the tier0-YYYYMMDD subdirectory, and KG2.8.0 subdirectory. Replace YYYYMMDD with the tier0 graph build date you are testing against. The KG2.8.0 houses an old DB file that is still used (COHDdatabase_v1.0_KG2.8.0.db).

cd Desktop/ARAX_DEV_DIR
mkdir DB_DIR
mkdir DB_DIR/tier0-YYYYMMDD
mkdir DB_DIR/KG2.8.0

ls Desktop/ARAX_DEV_DIR
DB_DIR
RTX

cd DB_DIR && ls
tier0-YYYYMMDD
KG2.8.0

To download the databases, you would need ssh access to arax-databases.rtx.ai as user rtxconfig; but if you do not have that, as long as you have ssh access to arax-databases.rtx.ai as user ubuntu, you can log in as ubuntu and configure ssh access as user rtxconfig, for yourself, like this:

scp ~/.ssh/id_ecdsa.pub [email protected]:
ssh [email protected]
sudo sh -c 'cat id_ecdsa.pub >> /home/rtxconfig/.ssh/authorized_keys'
sudo chown rtxconfig:rtxconfig /home/rtxconfig/.ssh/authorized_keys
sudo chmod 600 /home/rtxconfig/.ssh/authorized_keys

Then you can download files like this:

scp [email protected]:KG2.8.0/COHDdatabase_v1.0_KG2.8.0.db DB_DIR/KG2.8.0/

After downloading the databases, the DB_DIR directory structure would look like this:

cd KG2.8.0 && ls
COHDdatabase_v1.0_KG2.8.0.db

cd ../tier0-YYYYMMDD && ls
ExplainableDTD_v1.0_tier0-YYYYMMDD.db
autocomplete_v1.0_tier0-YYYYMMDD.sqlite
curie_ngd_v1.0_tier0-YYYYMMDD.sqlite
curie_to_pmids_v1.0_tier0-YYYYMMDD.sqlite
fda_approved_drugs_v1.0.pickle
tier0-info-for-overlay_v1.0_tier0-YYYYMMDD.sqlite

2. You will need to install the script generate-db-symlinks.sh into your ARAX_DEV_DIR and make it executable:

cd ARAX_DEV_DIR
curl -o generate-db-symlinks.sh -s -L \
  https://raw.githubusercontent.com/RTXteam/RTX/refs/heads/master/code/generate-db-symlinks.sh
chmod a+x generate-db-symlinks.sh

Next, you'll need to edit the shell script generate-db-symlinks.sh with the absolute path to your db directory:

DB_DIR="/home/you/Desktop/ARAX_DEV_DIR/DB_DIR"
LATEST_TIER0_VER="tier0-YYYYMMDD" # which must match the name of your tier0-YYYYMMDD folder and the date in config_dbs.json

Lastly, it is very important that you make sure the filenames in the script match exactly what is in code/config_dbs.json, and what is in DB_DIR/tier0-YYYYMMDD. Sometimes, small changes happen where v1.0 becomes v1.1 or an extension gets added on to the file name.

3. Create a file ARAX_DEV_DIR/flask_config.json containing the following JSON:

{
    "port": 5001,
    "check_databases": false,
    "run_background_tasker": false,
    "force_disable_telemetry": true,
    "query_fork_mode": false
}

4. Make sure you have ssh access to [email protected]. You need to set up the ssh public key exchange and put your public key in the file /home/araxconfig/.ssh/authorized_keys on araxconfig.rtx.ai, and you should do a test login to araxconfig.rtx.ai using this ssh key,

ssh [email protected]

to ensure that the IP address for araxconfig.rtx.ai is in your ~/.ssh/known_hosts file.

Once you're done with these steps, you are ready to work on a maintenance task for ARAX; continue with the procedure in the next section, which you should follow (from that section's beginning) for each ARAX maintenance task that you work on. For extensive documentation on the flask_config.json file schema, see the relevant section of the ARAX wiki.

It is possible that TCP port 5001 is already in use on your computer, by some other running process. If so, you will get an error when you try to start up ARAX and you'll need to change the port number in your flask_config.json file to some other number (say, "5002") and remember to change "5001" to "5002" wherever you see it in the instructions below). To see if port 5001 is already in use, you could run

netstat -an | grep tcp | grep ':5001'

and see if you get any results.

1. Expectations for bug reporting in ARAX If you have a query graph (JSON or ARAXi/DSL) that you were running when you encounter a bug, it is vital that you paste the JSON or ARAXi into the issue. In the issue, you should also describe what happens when the JSON or ARAXi query graph is run through ARAX, that is not correct/expected behavior. This is essential so that the maintainer can know whether or not they have successfully reproduced the bug. Please include information such as:

   • The ARAX host that you ran your query on
   • The date/time (including timezone) when you ran your query
   • If you have it, the relevant excerpt from the ARAX ".elog" file (/tmp/RTX_OpenAPI_DEVAREA.elog), where DEVAREA is one of beta, test, devED, devLM, legacy, or shepherd.
   • Screencaps of any relevant information that you are seeing in the ARAX User Interface.
   • Relevant excerpts of the message log from ARAX, which you may be able to get through the ARAX User Interface (depending on the severity of the bug).

2. If no one has done so already, create a GitHub issue in the RTXteam/RTX issue tracker. In the issue metadata in GitHub, under "Type", select bug, feature, or task, as appropriate. Further, under "Labels", select "High Priority" if you know that it is a high-priority issue. Often, maybe a third of the time, there is a "parent issue" in some other GitHub project area (e.g., NCATSTranslator/Feedback) that documents an issue someone saw in the Translator UI, that has been traced to ARAX. It is vital that the two issues reciprocally hyperlink one another: in the RTXteam/RTX issue, the parent issue (i.e., the one in NCATSTranslator/Feedback or wherever) should be hyperlinked (with some comment like "cross-post status updates in the parent issue here:", and in the parent issue, the RTXteam/RTX issue needs to be hyperlinked (with some comment like "ARAX team is working on this; for the latest status, check here:"). If you are claiming an issue in the issue tracker, you should assign it to yourself so that others will know that the issue has been claimed. Feel free to tag others whose input you want, via a comment, or, where you are confident that it is appropriate, co-assigning them to the issue (in which case, make it clear in the issue comment that you are taking the lead on working on the issue).

3. Create a branch called issue-XXX to work on the issue (where XXX is the issue number). In most cases, you will want to branch off of master, but in rare cases, the issue-XXX branch might need to be branched off of another (non-master) branch, for example, if you are addressing an issue with a feature in ARAX that is not yet merged to master but is only present within some other feature branch (note, this is highly unusual). In the RTXteam/RTX issue, add a comment noting the branch that you are working on, with a message like "Working on this issue in new branch issue-XXX."

4. On your development machine, you work out of a single clone of the ARAX code in ARAX_DEV_DIR (next to DB_DIR and generate-db-symlinks.sh), and switch branches for each issue. The layout looks like this:

ARAX_DEV_DIR/
├── DB_DIR/
├── RTX/
├── venv/
├── flask_config.json
└── generate-db-symlinks.sh

The first time only:

• clone the ARAX GitHub project area code into ARAX_DEV_DIR;
• create a python3.12 virtualenv called venv;
• install ARAX's distribution package dependencies (for both running ARAX, which is requirements.txt, and analyzing ARAX code, which is dev-requirements.txt) into the venv virtualenv;
• run the generate-db-symlinks.sh script to set up the database symbolic links (do it EXACTLY as shown, with your CWD being ARAX_DEV_DIR, the directory that contains RTX);
• copy the flask_config.json file to the RTX/code/UI/OpenAPI/python-flask-server/openapi_server subdirectory.

cd ARAX_DEV_DIR
git clone [email protected]:RTXteam/RTX.git
python3.12 -m venv venv
venv/bin/pip install -r RTX/requirements.txt
venv/bin/pip install -r RTX/dev-requirements.txt
./generate-db-symlinks.sh
cp flask_config.json RTX/code/UI/OpenAPI/python-flask-server/openapi_server/

The database symlinks, flask_config.json, and the KP info cache are all ignored by git, so they stay in place when you switch branches.

Make sure your working tree is clean (commit or stash any changes from your previous issue), then switch to the issue branch and refresh the KP info cache:

cd ARAX_DEV_DIR/RTX
git status
git fetch origin
git checkout -b issue-XXX origin/master
git push -u origin issue-XXX
cd code && ../../venv/bin/python -u -m ARAX.ARAXQuery.Expand.kp_info_cacher

If the branch changed requirements.txt or dev-requirements.txt, re-run the two pip install commands from ARAX_DEV_DIR. If it changed code/config_dbs.json, download any new database files, update generate-db-symlinks.sh to match, and re-run ./generate-db-symlinks.sh from ARAX_DEV_DIR.

After each command, make sure you look for successful completion before issuing the next command. The KP info cache command, if it completes successfully, should produce this final line of output:

The process with ID 61928 has FINISHED refreshing the KP info caches

Assuming you have completed all the steps in the section "Per-task procedure for ARAX maintenance", you should be ready to run ARAX locally on your development computer.

Before doing any development work, you should test ARAX to make sure it can run queries with the code that you currently have in the issue-XXX branch (which should at this point be the same as the code at the head of the master branch). This is done in two steps: running the unit test suite and then running the example queries through the ARAX Flask server locally.

Running the unit tests involves these steps:

cd ARAX_DEV_DIR/RTX
git checkout issue-XXX
../venv/bin/pytest -v

The procedure will take about 7-10 minutes to complete. All standard unit tests should pass, or your locally installed ARAX is not in a "known good" state (and you should work on troubleshooting the broken unit test before proceeding). Note, you should not run this test suite using pytest -v from within the RTX/code directory, as pytest will get confused and try to run the test files in UI/OpenAPI/python-flask-server/openapi_server/test.

1. Start the flask server locally, exactly as follows:

cd ARAX_DEV_DIR/RTX/code/UI/OpenAPI/python-flask-server
../../../../../venv/bin/python -u -m openapi_server

The output in your terminal session should look something like this:

sramsey-laptop:python-flask-server sramsey$ ../../../../../venv/bin/python -u -m openapi_server
Loading overly general concepts node file: /home/you/Desktop/ARAX_DEV_DIR/RTX/code/ARAX/ARAXQuery/Filter_KG/../../KnowledgeSources/general_concepts.json
Successfully loaded the blocklist file
Using JSON provider: CustomJSONProvider
Starting flask application with TCP port: 5001
 * Serving Flask app '__main__'
 * Debug mode: off
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:5001
 * Running on http://10.197.154.29:5001
Press CTRL+C to quit

2. In a different window, run your web browser (Firefox or Chrome), and using the "File" menu, select "Open File...", and in the dialog box, navigate to ARAX_DEV_DIR/RTX/code/UI/interactive and select index.html. Now, in the ARAX User Interface page that renders in your browser, you will see an orange banner message appear, saying "Call to /meta_knowledge_graph failed; could not load predicates and node categories."; do not worry about that banner message, that is expected when you first load index.html on your local development computer, because the base URL for querying the ARAX back-end is not (yet) configured via Settings (see Step 3). Just click the "x" to delete the orange banner message.
3. On the navigation pane on the left-hand side, click on the Settings, and then change the "ARAX QUERY URL" textbox to contain exactly this string:

http://localhost:5001/api/arax/v1.4/query 

and click "update" (you may well have to widen your browser window to see the blue "update" button, which is to the right of the text box).

Note: if you are working on a remote server and using port forwarding, you might need to change the rtx.js script to get around browser security restrictions via something like:

sed -i 's/window\.location\.hostname/window.location.host/g' RTX/code/UI/interactive/rtx.js

4. In the navigation pane in the ARAX User Interface in your web browser, click on Query, click on JSON, and click on Example 1 (it's a tiny orange link just above the large empty text-box). Then click on "Post to ARAX". Compare the results that are listed under the "Results" navigation tab, to what you would see if you ran the Example 1 JSON query on arax.ncats.io/test or arax.ci.transltr.io. Repeat this procedure for Example 2, Example 3, and Pathfinder.
5. Click on the "Results" tab (on the left) and scroll down to look at the results. The results don't have to be exactly the same as what you see with the master branch code, but if you see any major unexpected differences, please report an issue (e.g., via the #deployment channel in the CATRAX Slack workspace) before proceeding; the reason for this is that if you aren't starting with a "known good" ARAX, it doesn't make sense to try to do new development. The exception to this guidance is if one of the standard KPs has suddenly broken one of the example queries in ARAX; in that case, we wouldn't expect the above tests to yield a successful result (and, in fact, it is essential to observe the failing example query before proceeding so we know we have reproduced the problem). But the case of a KP breaking one of our example queries is quite rare, so we will not address that scenario further in the procedure that follows.
6. Click on the "Messages" tab (on the left) and scroll down to look at the TRAPI message log. If you are running ARAX locally on a development system, you will see one TRAPI warning for sure:

WARNING:    Not saving response to S3 because I don't know the S3BucketMigrationDatetime

That is expected when you are testing ARAX on your local computer; don't worry about it. But any other TRAPI warning or error messages are a reason to compare the TRAPI message log from your branch, with the TRAPI message log that results when you run with the ARAX code from the master branch.

If your issue-XXX is a bug report that you or someone else has contributed, then you'll want to make sure you can reproduce the bug using your locally running ARAX. It is very hard to debug ARAX issues on a remote endpoint, so even if it takes some effort, it is generally advantageous to figure out how to reproduce the bug on your local development system. Often, this is just a matter of running the query graph JSON (or ARAXi) submitted with the issue. If you are aiming to work on an ARAX bug, and if you can't reproduce the issue locally on your development computer, ask for help before proceeding.

If possible, write a new unit test to exercise the bug (or not-yet-implemented feature) on your dev system (this is sometimes not reasonably possible, but if it is straightforward to do it, you are encouraged to do it). Unit tests go in the RTX/code/ARAX/test directory. This would provide a durable benefit for the project since any regression of that test case (e.g., due to future development work) will be detected.

Before working on any ARAX module, e.g., foo.py, run it through these checks

ruff check foo.py
mypy --ignore-missing-imports foo.py
pylint foo.py

to assess code quality and type-correctness at baseline. If there are minor "spot" issues, you can fix them. If there are major issues, please reach out for help to discuss how to proceed. Having these checks pass before you implement your bugfix or feature enhancement is critical for enabling these static analysis tools to catch errors that might be introduced as a side effect of your bugfix or feature enhancement.

Any module foo.py that you work on, should pass static code checks before you commit to your branch:

ruff check foo.py
mypy --ignore-missing-imports foo.py
pylint foo.py

where, in the case of pylint, "clean" means a score of at least 9.50. When maintaining legacy ARAX modules, it is OK to disable certain pylint errors via a comment if it is simply infeasible to fix (e.g., when pylint complains that the ARAX_expander.py module is too long, shortening that module is beyond the scope of typical bugfix and feature development work). There should be no errors from ruff or mypy. If you have JSON or YAML files that you have edited or added for your work on issue-XXX, you should syntax-check the JSON or YAML file with jq or yq.

For code formatting, style, and AI validation guidelines (as well as some constraints due to team preferences and due to the ARAX architecture), please refer to the ARAX Coding guidelines document in the ARAX Wiki.

Do not commit to the master branch; at this point, you should commit your bugfix or new feature code, to your issue-XXX branch. When committing, you should tag the issue number in the git commit message. You should also put a comment in the GitHub issue, just after your commit, indicating whether the commit is (or is not) expected to be a complete fix (basically a one-line status report). The commit procedure is simple, assuming your local issue-XXX branch is not behind the issue-XXX branch on the remote (which would be very unusual given how issue-specific development work on ARAX is typically done):

git commit -m '#XXX' module1.py module2.py module3.py
git push origin issue-XXX

Do not push your code to the master branch at this point.

You'll now want to test your code on arax.ncats.io, on one of the available development "devareas" (/beta, /test, etc.). The steps below assume you'll be testing in /beta. The procedure is as follows:

1. Put a message on the #deployment channel in the CATRAX Slack workspace, that you are "Working on arax.ncats.io/beta, for ARAX issue XXX". Wait at least 10 minutes for someone to respond. If there are no objections, proceed:
2. ssh arax.ncats.io
3. sudo docker exec -it rtx2 bash
4. su - rt
5. cd /mnt/data/orangeboard/beta/RTX
6. git status
   Note the branch and whether there are local changes. If the local RTX code is not currently on the master branch, and/or if there are locally modified modules or config files (not counting untracked files), then someone else is _probably already using arax.ncats.io/beta for testing, and you should reach out before proceeding. Only proceed if there are no locally modified tracked files and the local code repository is on master. Staying in the same RTX directory:
7. git fetch origin
8. git checkout issue-XXX
9. git pull origin issue-XXX
10. Run all the pytests, using your updated code: pytest -v
    All standard ARAX unit tests should pass, when run in the arax.ncats.io/beta devarea. It is generally not a good idea to run pytest --lf (which reruns only the tests that previously failed), unless you really know what you are doing; with a complex legacy code-base like ARAX, it is easy for a well-intended bugfix to break other tests that were previously passing before the bugfix was introduced.
11. Next is to run the example queries, using your updated code. You will need to restart ARAX. Exit out of the shell session for user rt, by typing exit. You should see the root account prompt #:
12. Stop ARAX: service RTX_OpenAPI_beta stop
13. Verify that ARAX is stopped: ps axwf | grep 5003
    If you see any processes with the substring "5003" in the process title (which identifies them as coming from the /beta devarea), you should kill them with kill -9 PID.
14. Start ARAX: service RTX_OpenAPI_beta start
15. Follow ARAX start-up: tail -f /tmp/RTX_OpenAPI_beta.elog You will know that ARAX is ready when you see this in the .elog file:

2026-03-24T02:02:06.369294: INFO: ARAXBackgroundTasker: Completed meta KG refresh successfully

and you don't see a stacktrace or other obvious error message. 16. Go to your web browser and navigate to https://arax.ncats.io/beta and run the Example 1, Example 2, Example 3, and Pathfinder queries and verify that they completed successfully. If a pytest fails or one of the example queries fail, do not continue on this checklist; you need to debug the issue.

Often, fixing an issue can take a while, and this can lead to the appearance of new commits in master since your issue branch was created. In that case, it is best practice to merge master into your issue branch, and re-testing (both unit tests and integration tests), to make sure that updates in your issue branch "work" with the latest code in the master branch.

1. Open a Pull Request (for merging issue-XXX into master) for your issue and enter a succinct description of the issue in the pull request. Add a comment in issue XXX linking the PR. Assign someone to review the pull request. In the issue-XXX issue in GitHub, under "Labels", select "Waiting for PR review".
2. Comment /deploy on the pull request to build an isolated preview of your branch on cicd.rtx.ai. The bot posts the URL https://cicd.rtx.ai/<PR>/ once it is up, then comments with the smoke checks, the pytest results, and the four example queries (Example 1, Example 2, Example 3, Pathfinder) run against the live endpoint. Confirm the unit tests and the example queries pass. This is the automated alternative to the manual arax.ncats.io/beta run above, so it does not need an SSH session or a shared devarea. Use /redeploy after a code-only push to restart the preview in about a minute, and /undeploy to remove it. A dashboard of every running preview and the host load is at https://cicd.rtx.ai/previews/. Notes: only repository members can run the commands, forks are not supported, and the branch must be reasonably up-to-date with master or the deploy is refused with a message to rebase.
3. Via comments in the pull request, indicate that your updated modules passed ruff, mypy, and pylint checks, and that the unit tests and example queries passed on the preview (or on arax.ncats.io/beta if you tested there instead).
4. Check back 15 minutes after you opened the PR, to see if GitHub's static checks flagged an issue. If there is an issue, fix it before merging.
5. In the PR page on GitHub, assign Copilot as a reviewer, and fix (or document why not fixing) any issues it raises. Sometimes Copilot raises "security issues" that are not relevant because, for example, they are related to debug messages in our unit tests. Nevertheless, Copilot does catch bugs and it is worth running.
6. Once the PR is approved, give a warning message on #deployment ("Merging PR XXY for issue XXX, to ARAX master branch"). If it is a large merge or with particular risk for impacts on ARAX in CI, consider also messaging the #outages channel (and if ARAX is going to be down in CI, consider using the @channel tag in your message) in the NCATSTranslator Slack workspace, a message that there will be a restart of ARAX in CI, with new code.
7. Merge the PR using GitHub's green "Merge pull request" button. IMPORTANT: Before merging, please verify that the PR's base branch is master and its head branch is issue-XXX. Warning about merge conflicts: GitHub's web-based conflict-resolution tool merges the entire PR base branch into its head branch. For a normal PR from issue-XXX into master, resolving conflicts therefore modifies issue-XXX, not master. When updating an issue branch with changes from master, you should perform the merge locally (git checkout issue-XXX; git merge master), resolving conflicts carefully, testing, and pushing the updated issue branch. Never create or merge a pull request from master into an issue branch. If an issue branch needs to incorporate changes from master, perform the merge locally using git, resolve any conflicts locally, test the result, and push the updated issue branch.

If for some reason a pull request is not feasible or if you need to merge your feature branch into the master branch using the git command-line, you can just cd into a local fresh checkout of the master branch code and run

git fetch origin
git merge origin/issue-XXX

Please see the diagram below for visual understanding of the process:

For a long-running feature branch (typically complex projects), your feature branch (i.e., issue-XXX branch) may get well behind the head of the master branch. To bring your issue-XXX branch up-to-date with the head of master, do the following:

git checkout issue-XXX
git fetch origin
git rebase origin/master

This avoids introducing additional commit messages from master into your issue-XXX branch.

1. Message the #deployment channel in the CATRAX Slack workspace that you are doing work on arax.ncats.io/beta; on the arax.ncats.io system, inside the rtx2 container, in the /mnt/data/orangeboard/beta/RTX directory, switch back to the master branch and restart ARAX:

ssh arax.ncats.io
sudo docker exec -it rtx2 bash
su - rt
cd /mnt/data/orangeboard/beta/RTX
git fetch origin
git checkout master
git pull origin master
exit

Now you are root with the # prompt:

service RTX_OpenAPI_beta stop
service RTX_OpenAPI_beta start
tail -f /tmp/RTX_OpenAPI_beta.elog

If you had to fix merge conflicts or if your issue branch was behind master when you merged, rerun all the pytests. In any case, you will need to test the ARAX User Interface again with the Example 1 query. If everything is working, then proceed. 2. Change your local ARAX_DEV_DIR/RTX code branch to the master branch:

cd ARAX_DEV_DIR/RTX
git fetch origin
git checkout master
git pull origin master

3. An hour after merging your PR, check the ARAX Test Build (CI/CD test suite) in GitHub, to ensure it ran successfully.
4. Test your bugfix or new feature, if possible, on arax.ci.transltr.io. If ARAX does not come back up on arax.ci.transltr.io within 15 minutes of your merge, ask for help on #deployment.
5. Check on Slack and in GitHub notifications, to see if there have been any reports of problems on ARAX in CI or on arax.ncats.io/beta, since you merged your PR for your issue.

1. In GitHub, delete the issue-XXX branch and add a comment in the issue indicating "Branch issue-XXX deleted." Note, do not delete the branch so early that it causes the "Test Build" to fail. Make sure you verify that the Test Build has completed before you delete the issue branch.
2. Update the ARAX ChangeLog issue (by editing the top comment in the issue) giving a succinct description of your "fix" for issue-XXX and tagging the issue with #XXX.
3. Add an item for the next ARAX All-Hands Meeting agenda, called "ARAX issue XXX: fix merged".
4. If there is a "parent issue" (e.g., in NCATSTranslator/Feedback), add a comment to that issue indicating that ARAX issue XXX is fixed and merged to the master branch. This will allow the parent issue stakeholders (e.g., the TAQA team) to rerun their test or reproducible example for the issue.
5. Update any documentation (e.g., in the ARAX wiki) relevant to your feature or bugfix.
6. At the next ARAX all-hands meeting, make sure you are present so you can give a brief update on the outcome of your work on issue-XXX.
7. In the CATRAX milestones tracker for Year 2 project area on GitHub, in the issue tracker, make sure you find a milestone that is relevant to your issue and add a comment to that issue, with a hyperlink to the issue that you worked on, and your @username GitHub handle. This ensures that at the end of the budget period, your work on ARAX issues will be accounted for (in aggregated summary form) in the progress report to NCATS.

1. If you are getting inconsistent results from the pytest suite, like a test that is stubbornly failing on your development machine but working elsewhere, try deleting the TRAPI query cacher database like this:

rm ARAX_DEV_DIR/RTX/code/ARAX/ARAXQuery/Expand/trapi_query_cacher_database.sqlite
rm -r -f ARAX_DEV_DIR/RTX/code/ARAX/ARAXQuery/Expand/trapi_query_cacher_responses/

and then rerunning the pytest suite.