Filer: Unable to display "IA" (or Reg) after paying

[severinbeauvais]

(If this is a duplicate ticket, please close the ticket with the least helpful information.)

This was seen during a demo in Test. This has been seen previously while paying for a registration using a BCOL account but in this case it was a CC payment.

After clicking Exit, the My Business Registry page was able to show the completed registration (now a Firm).

Probably, clicking Retry would have displayed the firm's dashboard correctly.

~This may be because the firm was not fully created when payment was made.~ This shouldn't matter because the firm existed (using a temp reg number) previously and is still fetchable using its TRN, or its new FMxxx number.

The dev console shows an "Invalid auth roles" error. Travis captured some logs around this.

[severinbeauvais]

Sample error:

[severinbeauvais]

From Travis:

From last time:

Looks like fetch_user_settings and get_user_authorizations_for_entity happened before create_affiliation

2022-10-04 22:29:45,128 - auth_api - INFO in affiliation:affiliation.py:268 - delete_affiliation: <delete_affiliation org_id:1845 business_identifier:TL0ZPkBFkZ
2022-10-04 22:29:45,156 - auth_api - DEBUG in authorization:authorization.py:93 - get_user_authorizations_for_entity: check roles=:['colin', 'system', 'edit', 'account_holder', 'exclude_service_fees', 'offline_access', 'uma_authorization', 'job']
2022-10-04 22:29:45,444 - auth_api - DEBUG in authorization:authorization.py:93 - get_user_authorizations_for_entity: check roles=:['colin', 'system', 'edit', 'account_holder', 'exclude_service_fees', 'offline_access', 'uma_authorization', 'job']
2022-10-04 22:29:45,561 - auth_api - DEBUG in entity:entity.py:60 - create_from_dict: Creating entity from dictionary {'businessIdentifier': 'TL0ZPkBFkZ', 'corpTypeCode': 'RTMP', 'name': 'FM1011332'}
2022-10-04 22:29:46,140 - auth_api - DEBUG in user_settings:user_settings.py:32 - fetch_user_settings: <fetch_user_settings 
2022-10-04 22:29:46,250 - auth_api - DEBUG in authorization:authorization.py:93 - get_user_authorizations_for_entity: check roles=:['public_user', 'ppr', 'edit', 'account_holder', 'offline_access', 'uma_authorization']
2022-10-04 22:29:47,782 - auth_api - INFO in affiliation:affiliation.py:138 - create_affiliation: <create_affiliation org_id:1845 business_identifier:TL0ZPkBFkZ
2022-10-04 22:29:47,800 - auth_api - DEBUG in affiliation:affiliation.py:146 - create_affiliation: <create_affiliation entity found
2022-10-04 22:29:47,801 - auth_api - DEBUG in affiliation:affiliation.py:182 - create_affiliation: <create_affiliation find affiliation
2022-10-04 22:29:48,602 - auth_api - INFO in affiliation:affiliation.py:268 - delete_affiliation: <delete_affiliation org_id:1845 business_identifier:NR 2682087

[severinbeauvais]

@seeker25 Do you have a feel for whether this is in Legal API or Auth API?

[seeker25]

I'd have to take a look, I think the GUI there isn't AUTH it's an entity frontend.. but it's redirecting before the entity filer is done.

I don't think we have any indication the entity filer is complete without making an affiliation call?

We could make some sort of retry logic and it would be the quickest way to solve this problem I believe..

[severinbeauvais]

I'd have to take a look, I think the GUI there isn't AUTH it's an entity frontend.. but it's redirecting before the entity filer is done.

Yes, this is Filings UI trying to load the business using its temp reg number after an IA/Reg was filed. But the user was in Filings UI right before the IA/reg, so did the affiliations change as part of the filing? AFAIK, the business remains affiliated to the account using its temp reg number, and also using its new business id after the Filer is done with it.

@lekshmimallika-aot @argush3 Any comment about affiliations and filing an IA/Reg?

[argush3]

@severinbeauvais it is true that the business remains affiliated to the account using its temp reg number, but upon completion of processing a registration/IA, the temp reg affiliation is actually deleted for a moment.

After the deletion, the affiliation is re-created. If the FE calls the /api/v1/entities/<temp_reg_num>/authorizations auth endpoint right between temp reg affiliation deletion and re-creation, I think we get this scenario.

The logs provided by @seeker25 show this scenario I think.

Did we just want to try adding a re-try in Create UI?

[severinbeauvais]

Thanks for investigating. I'm surprised that we've seen this a few times recently, and never previously (afaik).

I assume lines 65 and 66 are both network calls, so there could be a second or more between them? Do you think combining those into a single, atomic operation would be a better option?

Yes, fetchData() in Filings UI could be coded to retry once automatically (and there is already a Retry button in the dialog shown to the user). It doesn't fit well into the existing architecture so it would be kind of a hack, lol. I'd be OK with that temporarily, if needed. Estimate: less than 1/2 day.

[argush3]

Thanks for investigating. I'm surprised that we've seen this a few times recently, and never previously (afaik).

Yes, it's interesting how it started happening. Just the right balance I guess 😀

I assume lines 65 and 66 are both network calls, so there could be a second or more between them? Do you think combining those into a single, atomic operation would be a better option?

Not sure if that would resolve the issue. I think we would still see it even if it happened less. At eod, we are still making separate api calls to auth for the various operations.

[argush3]

After some investigation, it has been determined that we can fix this in the Filings UI.

Un-assigning and putting this back into sprint backlog

[severinbeauvais]

I assume lines 65 and 66 are both network calls, so there could be a second or more between them? Do you think combining those into a single, atomic operation would be a better option?

Not sure if that would resolve the issue. I think we would still see it even if it happened less. At eod, we are still making separate api calls to auth for the various operations.

I was thinking one call to Auth API, and on their side it could be a db update call.

[argush3]

I don't think it makes sense to make this one Auth API call. The code here actually results in 4 calls to the Auth API.

AccountService.delete_affiliation() deletes the old temp reg affiliation and deletes the entity.

AccountService.create_affiliation() creates a new entity and a new temp reg affiliation.

I think bunching all these calls into one call under a separate auth endpoint is probably not desirable.

Thoughts @seeker25 ?

[seeker25]

Use queues instead with a worker to handle most of the synchronization for affiliations and entities in auth that needs to be done via LEAR and Namex

Leave the affiliation and entity endpoints in auth-api for mostly front facing clients/staff, But that's quite a bit of work

There's alot of creates and deletes, when some of the actions should be updates. Also many requests.. if one fails in the chain it's hard to figure out..

Multiple affiliation is coming up and Lekshmi and me have put in a bit of work around code for now:

https://github.com/bcgov/sbc-auth/blob/3c6c45da21689071dceed3be919acd3c60b3e197/auth-api/src/auth_api/services/affiliation.py#L317

Otherwise entities would be out of "sync".

There is also very little logging in DEV/TEST to let us know where the errors are for entity-filer because quite a bit of it relies on sentry which is disabled in DEV/TEST I believe. Sure you could see the 500.. but no real indication of where in the code they are happening etc.

[severinbeauvais]

So... is our best course of action to (temporarily) code in a retry mechanism in Filings UI?

[argush3]

I think so

[seeker25]

@argush3 could we just use a PUT/PATCH on the entity instead of a POST/DELETE on the entity / affiliation

[severinbeauvais]

Blocked while Travis' suggestion above is investigated by a LEAR BE dev. If that can't be done easily or quickly then we're back to adding retry in the UI (but I hope that's the last option).

[argush3]

@seeker25 I think your suggestion of a PUT/PATCH on the temp reg entity works. I just did a deeper dive and tested creating a draft registration and filing it to completion to get a more complete view of how things change in auth according to the LEAR affiliation code right now.

[severinbeauvais]

I assume we need an Auth API ticket and there's a dependency here.

Travis, when can your team fit this in? We will (re)schedule THIS ticket accordingly. (I know THIS ticket has label Priority 1 but there's a workaround: user can just click Retry on the error modal.)

[argush3]

No, I don't think an auth ticket is required. It looks like PATCH is already available for the entities resource from what i can see. I need to touch base with Thor about taking this approach just in case though.

[seeker25]

Yup -^

[severinbeauvais]

Thanks Argus and Travis! <so happy>

[argush3]

@severinbeauvais the filer update is in DEV now. I'm doing some testing but you can try to break it if you want too :)

[argush3]

Ready for verification.

I have tested creating a SP/GP/CP/BEN in DEV and did not run into the issue described in the ticket description. i.e. no unable to access IA/registration information dialogue came up.

Filer logs were also verified to confirm no delete affiliation and entity calls were made to Auth API for the temp registration/IA entity. Only an update entity call was made for the temp registration/IA entity to the Auth API.

@riyazuddinsyed this might be a little hard to test but I think you can try a bunch of registration and IAs for different legal types to see if you get the error dialogue. @severinbeauvais mentioned he would experience this issue around 10% of the time. It is also something to just monitor over time as well.

[seeker25]

taking myself off the assignment list, I don't think I have to do anything

[severinbeauvais]

Right. Thanks for the help, Travis.