Saltar al contenido principal

wiki-Documentación

Ver en Git

Documentación

SYNCHRONIZER

todas las fechas en formato UTC: YYYY-MM-DDTHH:MM:SSZ

Objeto request​
  • request_date: "2023-09-20T00:00:06Z" README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests fecha de la request. importante porque se usa para el orden en que se ejecutan
  • request_id: "cd45aea9-c4c7-4bb2-8442-e5e49c075157"
  • request_method: "POST" README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests uno de 'POST', 'PATCH', 'GET', 'PUT', 'DELETE'
  • request_endpoint: "/api/layers/scale/last_view"
  • request_args: "param1=asd&param2=qwe" README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests tambien se puede poner en request_endpoint. no enviar ambos
  • request_body: "{}"
  • request_headers: {} README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests objeto con los headers TAL CUAL LOS TIENE QUE ENVIAR EL SYNCHRONIZER
  • last_response_status: null README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests int, es el status http de la ultima respuesta. esto lo setea el servidor despues de un intento
  • last_response_content: null README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests str, es el content de la ultima respuesta. esto lo setea el servidor despues de un intento
  • last_attempt_timestamp: null README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests str, es la fecha de ultimo intento
  • sync_status: "pending" README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests str, estado de la request: 'pending' | 'ready' | 'retry' | 'error' | 'skipped'
Objeto queues​
  • queue_name: "sarasa4",
  • queue_id: "f22488b4-fd7d-4a47-ae35-3091d536a778",
  • queue_metadata: {},
  • sync_requests: [<OBJETO_REQUEST>, ...],
  • received_at: "2023-09-20T12:19:49Z",
  • last_attempt_timestamp: "2023-09-20T12:22:18Z", README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests lo pone el servidor
  • status: "ready" README.md celery-health.sh core docker docker-compose.yml docs migrations requirements.dev.txt requirements.txt run_api.py run_celery.sh src tests str, estado de la queue. Es calculado a partir del estado de sus requests: 'pending' | 'queued' | 'ready' | 'error'

Sincronización​

La sincronización se realiza de manera async por un worker. Se toman todas las queues pendientes de un usuario y se ejecutan en serie en el orden que las recibió el servidor. Esto significa que si una request falla, todas las requests y queues que le siguen quedarán encoladas.

Ciclo de status​

Cuando se crea una queue, se crea en status pending. Significa que está en "standby". Todas las requests asociadas son creadas con status pending. Enseguida luedo de ser creada, se dispara la tarea de sincronización y se la pasa a queued.

Al ejecutarse cada request:

  • Si el servidor responde con 20X, pasa a ready.
  • Si el servidor responde con un status distinto de 20X, la request pasa a error.
  • Podría darse el caso en que no se obtenga respuesta del servidor (por ejemplo timeout), en ese caso pasa a retry.

Si una request pasa a retry o error, la sincronización se detiene, por lo que el resto de requests se mantiene en pending.

Cuando todas las requests son sincronizadas o la sincronización se detiene, se recalcula el status de la queue.

  • Si todas las requests están en ready, la queue pasa a ready
  • Si alguna está en retry o error, la queue pasa a error y las siguientes queues (de haber) pasan a pending.

Se pueden eliminar requests. Esto es, pasarla a status skipped que implica ignorarla en el cálculo del status de la queue. Luego de eliminar una request, se recalcula el status de la queue.

Un flujo típico sería:

  1. Se crea la queue y se envía la tarea de sincronización.
  2. Se ejecutan las requests hasta que una falla.
  3. Se elimina la request que falló.
  4. Se dispara la tarea de sincronización nuevamente.
  5. Las requests restantes se ejecutan con éxito.

APIs​

API_URL = http://api.testing.auravant.com

obtener el estado de sync.​

GET /sync/status

Respuesta

{
 "info": "ok",
 "data": {
 "status": "error"
 }
}

subir una queue.​

POST /sync/queues

Body:

 {
 "queue_name": "sarasa4",
 "queue_id": "f22488b4-fd7d-4a47-ae35-3091d536a788",
 "queue_metadata": {},
 "sync_requests": [
 {
 "request_date": "2023-09-20T00:00:05Z",
 "request_id": "d03f4194-0df3-4338-8e05-de679d89588e",
 "request_method": "POST",
 "request_endpoint": "/api/layers/scale/last_view",
 "request_args": "param1=asd&param2=qwe",
 "request_body": "{}",
 "request_headers": {"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzcmMiOiJ3IiwidWlkIjo3Mzg4LCJleHAiOjE2OTc3OTI4MTYsImlhdCI6MTY5NTIwMDgxNiwibG9jYWxlIjoiZW5fVVMiLCJ1dCI6MiwiZGV2IjoxLCJhaWQiOjcxODB9.FZMWpyRmXOmpKEsd4OZMUpQNAjPA8Ke5Ila1F9Z5RNw", "X-Version": "2.2.2"}
 },
 {
 "request_date": "2023-09-20T00:00:06Z",
 "request_id": "cd45aea9-c4c7-4bb2-8442-e5e49c075157",
 "request_method": "POST",
 "request_endpoint": "/api/layers/scale/last_view",
 "request_args": "param1=asd&param2=qwe",
 "request_body": "{}",
 "request_headers": {"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzcmMiOiJ3IiwidWlkIjo3Mzg4LCJleHAiOjE2OTc3OTI4MTYsImlhdCI6MTY5NTIwMDgxNiwibG9jYWxlIjoiZW5fVVMiLCJ1dCI6MiwiZGV2IjoxLCJhaWQiOjcxODB9.FZMWpyRmXOmpKEsd4OZMUpQNAjPA8Ke5Ila1F9Z5RNw", "X-Version": "2.2.2"}
 }
 ]
 }
  • Por ahora, si envias con el mismo uuid, se pisa

obtener queues pendientes.​

GET /sync/queues

Respuesta:

{
 "info": "ok",
 "data": {
 "queues": [
 {
 "queue_name": "sarasa4",
 "queue_id": "f22488b4-fd7d-4a47-ae35-3091d536a778",
 "queue_metadata": {},
 "received_at": "2023-09-20T12:19:49Z",
 "last_attempt_timestamp": "2023-09-20T12:22:18Z",
 "pending": true,
 "sync_requests": [
 {
 "request_date": "2023-09-20T00:00:06Z",
 "request_id": "1af9cf0d-db0a-47f3-8fe5-f60d6a5f69d3",
 "request_method": "POST",
 "request_endpoint": "/api/layers/scale/last_view",
 "request_args": "param1=asd&param2=qwe",
 "request_body": "{}",
 "request_headers": {
 "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzcmMiOiJ3IiwidWlkIjo3Mzg4LCJleHAiOjE2OTc3OTI4MTYsImlhdCI6MTY5NTIwMDgxNiwibG9jYWxlIjoiZW5fVVMiLCJ1dCI6MiwiZGV2IjoxLCJhaWQiOjcxODB9.FZMWpyRmXOmpKEsd4OZMUpQNAjPA8Ke5Ila1F9Z5RNw",
 "X-Version": "2.2.2"
 },
 "last_response_status": 400,
 "last_response_content": "{\"info\": \"Parameters error\", \"res\": \"error\", \"code\": -5, \"msg\": \"'layer_name' is a required property\"}",
 "last_attempt_timestamp": "2023-09-20T17:07:10Z",
 "sync_status": "error"
 },
 {
 "request_date": "2023-09-20T00:00:06Z",
 "request_id": "cd45aea9-c4c7-4bb2-8442-e5e49c075157",
 "request_method": "POST",
 "request_endpoint": "/api/layers/scale/last_view",
 "request_args": "param1=asd&param2=qwe",
 "request_body": "{}",
 "request_headers": {
 "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzcmMiOiJ3IiwidWlkIjo3Mzg4LCJleHAiOjE2OTc3OTI4MTYsImlhdCI6MTY5NTIwMDgxNiwibG9jYWxlIjoiZW5fVVMiLCJ1dCI6MiwiZGV2IjoxLCJhaWQiOjcxODB9.FZMWpyRmXOmpKEsd4OZMUpQNAjPA8Ke5Ila1F9Z5RNw",
 "X-Version": "2.2.2"
 },
 "last_response_status": null,
 "last_response_content": null,
 "last_attempt_timestamp": null,
 "sync_status": "pending"
 }
 ]
 }
 ]
 }
}

forzar sync.​

POST /sync/status
POST /sync/status ? user_id=123456

si se agrega el parametro user_id, se simula una api de sudo.

borrar una request.​

DELETE /sync/requests ? request_id=cd45aea9-c4c7-4bb2-8442-e5e49c075157

Base de datos​

Por ahora la base de datos es un archivo de texto en /home/ubuntu/synchronizer/database.json. Si se modifica ese archivo, se puede "arreglar" la sincronización.