- we are not setting this property, and it's inclusion in this model
with a default false value meant that there were no errors with seeded
data, but with the data returned from the db_manipulation there was.
- Refactoring without tests makes it riskier
- Move some tests from resolver to middleware unit tests to live closer
to where the validation happens, remove duplicate tests
- DRY out code
- Update seed file with more human readable imageAspectRatios
- Remove copy script from Dockerfile to not expose to others. we'll need
to either start a maintenance server, so it has access to both the
backend/public/uploads and cypher-shell, or copy a script to the backend
that creates a csv, which can be copied to the neo4j pod and then loaded
into the cypher.
- Remove unintended changes to deployment/legacy-migration
- Add back image compression to Post images
We had this error in our neo4j pod recently:
```
2019-12-02 08:29:42.680+0000 ERROR Unable to schedule bolt session 'bolt-1018230' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.680+0000 ERROR Unable to schedule bolt session 'bolt-1018224' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.681+0000 ERROR Unable to schedule bolt session 'bolt-1018352' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
2019-12-02 08:29:42.682+0000 ERROR Unable to schedule bolt session 'bolt-1018243' for execution since there are no available threads to serve it at the moment. You can retry at a later time or consider increasing max thread pool size for bolt connector(s).
```
Apparently the default is 400 threads. So we must have a leak somewhere.
Ok, so here is the plan. Let's give both our cucumber features and your
cypress tests a prominent place to live. That would be the root level
folder of our application. Second, let's revive formerly dead code step
by step.
Ie. move code from the former location `backend/features/` to `features/`
when it is ready. All edge cases should be tested with unit tests in
`backend/`, see my `webfinger.spec.js` as an example.
- update script
- use readTxResult for validateReview
- favor more verbose variables
- do not set review.closed as we close the report and the rule at the
moment is set to 'latestReviewUpdatedAtRules' rule, so it's clear the
last review must have been the one that closed the report
- Set up/tear down should not needlessly run http requests. These tests
are not designed to test that the report/review process works as
expected. that is the job of their respective unit tests/e2e tests.
- Don't throw error if a report already exists since we use MERGE and
that does not create a new resource if it exists. That is tested at the
neo4j(database) level.
- We also have a test to make in reports.spec.js that no duplicate is
created to ensure we didn't make some error on our part.
- Fix some faulty logic in validateReview
