| Age | Commit message (Collapse) | Author |
|---|
|
Refs #4293
|
|
|
|
|
|
|
|
af83/import--fix-parent-status-update-on-child-change
Import fix parent status update on child change
OH GOODNESS WHAT HAVE I DONE I SKIPPED ALL THE SPECS
|
|
Clean up this section a tiny bit. Should function the same way as
before.
|
|
Previously we were only updating the `ended_at` field when the import
had a 'successful' status. But there are other statuses that indicate
the import finished, and the `ended_at` field should be updated in these
cases also.
Committing what I have now which seems to work but I didn't write specs
for it because it was a pain to test (what with creating a child, etc.).
The `#update_status` method should be refactored to make testing the
`ended_at` update easier.
This needs to be committed without specs now because I'm off to go to a
client meeting and this work/branch is blocking QA of imports both
internally and externally. So I guess doing things right comes later.
That is to say, probably a lot later. Who knows.
|
|
A bunch of things that need to be written to get this in proper working
order.
|
|
This method is no longer used, now that we have Alban's `#update_status`
method.
Originally this was supposed to be used to determine if the import was
finished or not. Now, the parent import status field update doesn't
depend on it, and we can use the `Referential#ready` field to determine
whether or not to display the import in the interface.
|
|
After handling a status update of the parent import, if the parent
import finished, we should update its referential to `ready: true` so
that the referential actually gets displayed on the page.
|
|
Instead of just looking at the given child, the parent import status is
now determined by checking all children and assigning a value based on
their status.
This also updates the `current_step` (which was previously handled by
the `WorkbenchImportWorker`, remind me to remove it from where), and the
`ended_at` time. I think `ended_at` should probably be updated in both
successful and failed cases. Will have to make that update.
|
|
|
|
|
|
import
|
|
|
|
|
|
|
|
|
|
from real data. Refs #4273
|
|
|
|
|
|
and failed status in this case. Refs #4273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Robert recommended that this file should not live in concerns. Move it
somewhere else (maybe lib/ ?).
|
|
These tests were failing:
1) NetexImport POST netex_imports with correct credentials and incorrect request behaves like illegal attributes missing file does not succeed
Failure/Error: expect( json_response_body['errors'][bad_attribute.to_s] ).not_to be_empty
TypeError:
no implicit conversion of String into Integer
Shared Example Group: "illegal attributes" called from ./spec/requests/api/v1/netex_import_spec.rb:90
# ./spec/requests/api/v1/netex_import_spec.rb:77:in `[]'
# ./spec/requests/api/v1/netex_import_spec.rb:77:in `block (6 levels) in <top (required)>'
# -e:1:in `<main>'
2) NetexImport POST netex_imports with correct credentials and incorrect request name already taken behaves like illegal attributes missing name does not succeed
Failure/Error: expect( json_response_body['errors'][bad_attribute.to_s] ).not_to be_empty
TypeError:
no implicit conversion of String into Integer
Shared Example Group: "illegal attributes" called from ./spec/requests/api/v1/netex_import_spec.rb:96
# ./spec/requests/api/v1/netex_import_spec.rb:77:in `[]'
# ./spec/requests/api/v1/netex_import_spec.rb:77:in `block (6 levels) in <top (required)>'
# -e:1:in `<main>'
The problem was caused by the fact that the error messages come back
from `ErrorFormat` as an array of hashes, which contain a single key
corresponding to the invalid field.
Instead, the error messages should be returned as a single hash with a
bunch of keys corresponding to the invalid fields.
This change gets the above tests to pass.
|
|
|
|
|
|
|
|
This one doesn't do anything. The real one currently lives in
`app/models/concerns/error_format.rb` (it shouldn't live there according
to Robert, but for now that's the story).
|
|
This is no longer being used as the `WorkbenchImportWorker` was
refactored and it was decided that we don't want to enable retries for
imports.
For example, imagine you have an hour-long import that fails after 50
minutes. We retry three times and now we've wasted 2.5 hours of your
time just to tell you that the import failed.
Thus the decision was to remove it.
|
|
While testing imports with Alban, we saw that this request was blocking,
not asynchronous. The Java application apparently didn't figure that it
should close HTTP connections before handling a long-running import job.
In order to get around that on the Rails appliation side, Alban
suggested putting the request in a thread. Works like a charm, and we
respond in a sensible amount of time.
|
|
This param isn't permitted by the controller and we're currently not
using it for anything. It produces a warning message in the logs, so I
figured we should remove it. We may want to change the architecture to
create referentials outside of the API, and thus would have to add this
param in, but until then it's not needed.
|
|
|
|
imports#show
|
|
Refs #4280
|
|
Refs #4280
|
|
|
|
Retry removed (but not the deadcode yet) [amend me]
|
|
|
|
organisation code
|
|
|
|
|
|
|
|
|
