feat(auth): add event for grant revoked

[dragosp1011]

Changes proposed in this pull request

• Adds webhook workers in Auth service. The webhook url is optional as not all ASE will need to process these events (at least for now). If webhook url is not provided the workers are not started and the events are not saved in db.
• Implements grant.revoked event.
• Replaces trx with knex in some tests where trx was not defined before being used.

Context

fixes #2898

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Make sure that all checks pass
• Bruno collection updated (if necessary)
• Documentation issue created with user-docs label (if necessary)
• OpenAPI specs updated (if necessary)

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec canceled.

Name	Link
🔨 Latest commit	1368328
🔍 Latest deploy log	https://app.netlify.com/sites/brilliant-pasca-3e80ec/deploys/67fccc5026333e0008182efd

[github-actions]

🚀 Performance Test Results

Test Configuration:

• VUs: 4
• Duration: 1m0s

Test Metrics:

• Requests/s: 40.18
• Iterations/s: 13.41
• Failed Requests: 0.00% (0 of 2418)

📜 Logs

> performance@1.0.0 run-tests:testenv /home/runner/work/rafiki/rafiki/test/performance
> ./scripts/run-tests.sh -e test "-k" "-q" "--vus" "4" "--duration" "1m"

Cloud Nine GraphQL API is up: http://localhost:3101/graphql
Cloud Nine Wallet Address is up: http://localhost:3100/
Happy Life Bank Address is up: http://localhost:4100/
cloud-nine-wallet-test-backend already set
cloud-nine-wallet-test-auth already set
happy-life-bank-test-backend already set
happy-life-bank-test-auth already set
     data_received..................: 843 kB 14 kB/s
     data_sent......................: 1.7 MB 29 kB/s
     http_req_blocked...............: avg=7.54µs   min=2.31µs   med=5.49µs   max=1.23ms   p(90)=6.69µs   p(95)=7.29µs  
     http_req_connecting............: avg=964ns    min=0s       med=0s       max=966.08µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=98.84ms  min=12.44ms  med=82.57ms  max=575.2ms  p(90)=173.24ms p(95)=197.3ms 
       { expected_response:true }...: avg=98.84ms  min=12.44ms  med=82.57ms  max=575.2ms  p(90)=173.24ms p(95)=197.3ms 
     http_req_failed................: 0.00%  ✓ 0         ✗ 2418
     http_req_receiving.............: avg=90.31µs  min=30.03µs  med=79.79µs  max=2.91ms   p(90)=114.12µs p(95)=141.04µs
     http_req_sending...............: avg=37.87µs  min=9.59µs   med=28.38µs  max=2.63ms   p(90)=42.23µs  p(95)=54.35µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=98.71ms  min=12.25ms  med=82.47ms  max=575.14ms p(90)=173.14ms p(95)=197.22ms
     http_reqs......................: 2418   40.18316/s
     iteration_duration.............: avg=297.82ms min=181.94ms med=284.74ms max=1.16s    p(90)=369.48ms p(95)=401.36ms
     iterations.....................: 807    13.411005/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4 

[BlairCurrey]

definitely an edge case, but nothing is stopping them from setting a value of 0 for the webhookWorkers right? In which case it would just quietly not have any workers (even if url is set). Maybe we handle that somehow? I guess we could check that alongside webhookUrl, or maybe error when parsing the config?

[dragosp1011]

that is correct, but If events are not processed they also should not be stored. I check on saving the webhookUrl as well.

I think a separate env variable (ENABLE_WEBHOOK) that will state if the webhook is enabled or not will be best so the decision is more conscientious. All the checks to be depending on it after that.

[njlie]

Some degree of config parsing might still be necessary, as the scenario where ENABLE_WEBHOOK being true and WEBHOOK_URL being undefined or WEBHOOK_WORKERS being zero could still occur

[mkurapov]

Since this is unused, we can just remove it

[mkurapov]

For getPage we can also remove it, or add it to the auth GraphQL schema (webhookEvents query) to be used in a resolver method.

[mkurapov]

Since we don't have telemetry properly enabled in the auth project (like we do in backend), we can remove this for now.

[mkurapov]

@njlie with respect to multi-tenancy, I think we should make "make auth webhook events multi-tenanted" an item after we release multi-tenancy. What do you think?

[njlie]

@njlie with respect to multi-tenancy, I think we should make "make auth webhook events multi-tenanted" an item after we release multi-tenancy. What do you think?

Makes sense to me

[mkurapov]

@dragosp1011 will close this for now - this is something we would like to have in rafiki-v2, however.