Fix `REDCapR` revdep failure

[ezraporter]

Description

This PR regenerates the httptest mocks to be compatible with the latest version of REDCapR. Currently our renv.lock points towards the dev version of REDCapR but I imagine we won't push this until REDCapR 1.2.0 is on CRAN at which point we'll change that.

This also removes the custom error message for deleted REDCap projects introduced in #156. When regenerating the mocks I was not able to reproduce this error message with REDCapR 1.1.0 or 1.2.0. My guess is that this is due to updates to the CHOP REDCap instance which means checking for deleted as opposed to nonexistent REDCap projects is likely too fragile.

Proposed Changes

List changes below in bullet format:

• Regenerate mocks
• Remove custom error message for deleted REDCap projects and associated tests

PR Checklist

Before submitting this PR, please check and verify below that the submission meets the below criteria:

• [x] New/revised functions have associated tests
• [x] New/revised functions that update downstream outputs have associated static testing files (.RDS) updated under inst/testdata/create_test_data.R
• [x] New tests that make API calls use httptest::with_mock_api and any new mocks were added to tests/testthat/fixtures/create_httptest_mocks.R
• [x] New/revised functions use appropriate naming conventions
• [x] New/revised functions don't repeat code
• [x] Code changes are less than 250 lines total
• [x] Issues linked to the PR using GitHub's list of keywords
• [x] The appropriate reviewer is assigned to the PR
• [x] The appropriate developers are assigned to the PR
• [x] Pre-release package version incremented using usethis::use_dev_version()

Code Review

This section to be used by the reviewer and developers during Code Review after PR submission

Code Review Checklist

• [ ] I checked that new files follow naming conventions and are in the right place
• [ ] I checked that documentation is complete, clear, and without typos
• [ ] I added/edited comments to explain "why" not "how"
• [ ] I checked that all new variable and function names follow naming conventions
• [ ] I checked that new tests have been written for key business logic and/or bugs that this PR fixes
• [ ] I checked that new tests address important edge cases

[rsh52]

This also removes the custom error message for deleted REDCap projects introduced in https://github.com/CHOP-CGTInformatics/REDCapTidieR/pull/156. When regenerating the mocks I was not able to reproduce this error message with REDCapR 1.1.0 or 1.2.0. My guess is that this is due to updates to the CHOP REDCap instance which means checking for deleted as opposed to nonexistent REDCap projects is likely too fragile.

So what is the behavior now when a deleted project is called? The tryCatch generic message?

[ezraporter]

This also removes the custom error message for deleted REDCap projects introduced in #156. When regenerating the mocks I was not able to reproduce this error message with REDCapR 1.1.0 or 1.2.0. My guess is that this is due to updates to the CHOP REDCap instance which means checking for deleted as opposed to nonexistent REDCap projects is likely too fragile.

So what is the behavior now when a deleted project is called? The tryCatch generic message?

It will probably depend on your institution's REDCap instance but for CHOP it's returning 403 so we get this one: https://github.com/CHOP-CGTInformatics/REDCapTidieR/blob/82c8b8a67cdf59db9ac492208669e5218ad87553/R/utils.R#L645-L651

If I recall correctly, we were previously getting 404 with the message The REDCap project no longer exists because it was deleted although I can't recreate that to be sure. If a user gets that response they'll get that The REDCap project no longer exists... message in the error from REDCapTidieR.

[rsh52]

Got it thanks, I forgot we had updated the error message defaults to return what the REDCap API returns. In that case I think this should be good, in general it should be relatively rare that a read_redcap() call gets made against a deleted database. Only time I can see it popping up is for routine calls that are left on a schedule.

See what Will says but otherwise I think this looks fine.

[ezraporter]

@rsh52 this is ready for review. I made the following changes:

• Removed mocks
• Skip tests requiring API calls on CRAN
• Skip vignettes on CRAN
  • I believe the way I did this the vignettes will still show up on CRAN since they use the built versions bundled with the package. Worst case they'll only show up on our pkgdown site.
• Updated lintr and styler in renv.lock