NOTIFICACION SIN CITA ASIGNADA

[Eljeff13]

Les ha pasado que al correr el codigo y "encuentra" una cita, envia la notificacion de que asigno la cita, sin embargo no la asigna como tal en la API de la pagina? creo que se deba a un error de la API o que estas citas simplemente no se pueden asignar.

Por otro lado, he puesto el codigo a correr, sin embargo luego de un par de adelantos, me ha baneado mis redes de internet disponibles, la pagina me rechaza la conexion, saben como podria eliminar esto? o pasarme por alto, he tratado con VPN sin embargo parece que son un tanto lentas, cabe aclarar que estoy corriendo el codigo de forma local.

Gracias por su ayuda.

[dvalbuena1]

Este problema ya existe #21 y parece ser algo esperado ya que hay alguna restricción por parte de la API que aún se desconoce, lo que genera que llegue la notificación pero no se asigne realmente.

Respecto a la ejecución local no te ofrezco muchas opciones, la única es usar VPNs de pago que ofrecen mejores velocidades.

[Eljeff13]

la has usado con VPN? puedes recomendarme alguna? por otra parte sabes cuanto demora el "baneo" en quitarse? si monto la app en AWS tendria el mismo problema?

[dvalbuena1]

No suelo usar VPNs pero sé que la más popular es ExpressVPN. Y respecto al tiempo de baneo, sé que a alguien se le demoro unas 5 horas, no estoy seguro de si ese valor ha cambiado.

[Eljeff13]

Ahora mismo mi IP lleva Baneada unas 20 horas, al igual que en otro sitio donde me conecte y a las 6pm llevaba 24 horas de baneo.

[Eljeff13]

para tener en cuenta, el ban por Exceso de visitas tiene una duración de 3 dias, 72 horas.

[jrojas-qventus]

@Eljeff13 Dices que te adelanto? te funciono? a mi me manda mensaje de rescheduled pero no lo re agenda.

[Eljeff13]

si, parece ser un error de la API, o que hay interacción con otros bots y te ganan la cita, debes estar muy muy pero muy de suerte para que te reagende.

[Eljeff13]

@dvalbuena1 usted cree que estén "baneando" la solicitudes json?

[dvalbuena1]

No realmente, segun este comentario de otro usuario puede que simplemente haya alguna restriccion que desconocemos. https://github.com/dvalbuena1/visa_rescheduler_aws/issues/21#issuecomment-1939284408 Otra razon puede ser lo que mencionabas y es que tal vez en el segundo exacto otra persona intento reagender en el mismo horario. Pero por ahora es muy dificil saber.

[Eljeff13]

cree que podríamos tener otro enfoque para enviar el reagendamiento?

[dvalbuena1]

Pues en el momento la implementación se basa en llamar el API de la embajada directamente. La otra alternativa seria no hacer ese llamado directamente si no hacer la interacción manual en la pagina y de esta forma tal vez se podrian evitar esos agentamientos falsos. Este enfoque es mucho mas tedioso de implementar ya que toca interactura con un nuevo componente que es el calendario que se muestra al ver las fechas. Asi que no me comprometeria a realizar dicha implementación.

[Eljeff13]

@dvalbuena1 despues de testear con personas que no necesitan cita ASC he llegado a la conclusion que el problema esta en if NEED_ASC: asc_data = { "appointments[asc_appointment][facility_id]": ASC_ID, "appointments[asc_appointment][date]": asc_date, "appointments[asc_appointment][time]": asc_time } data.update(asc_data) si se intenta con cuentas que no necesiten esta cita, inmediatamente va a agendar la cita encontrada, tienes idea de como solucionar este inconveniente?

[amrondonp]

Estoy intentando para la embajada colombiana que SI necesita ASC. sin embargo, le quité la parte del ASC para ver si funcionaba. Estoy usando fiddler para inspeccionar las peticiones http, obtengo esto

El servidor responde con un 302 "you are being redirected" y pues obviamente no se puede agendar la cita.

Mi hipotesis es que hay otros bots que me ganan en agendar la cita, aunque como dice valbuena, es dificil saber.

El bot retorna 200 porque sigue las redirecciones de la URL. 2 para ser exactos. y eventualmente retorna 200

[dvalbuena1]

De hecho estuve haciendo algunas pruebas y pense que si podria ser que otro usuario al mismo instante intento agendar la cita, pero no es asi. Y me di cuenta que al intentar agendarla con ASC/CAS siempre genera el problema. Se obtiene codigo 200 como respuesta pero voy a validar y nada. Ademas, valido nuevamente y la misma fecha aun esta disponible asi que significa que nadie la tomo. Incluso intento hacer el proceso manual desde la pagina usando la misma fecha y funciona sin problema.

Lo que me parece muy extraño es que simplemente añadiendo las siguientes lineas al request se presente ese error.

asc_data = {
"appointments[asc_appointment][facility_id]": ASC_ID,
"appointments[asc_appointment][date]": asc_date,
"appointments[asc_appointment][time]": asc_time
}

En el momento estoy analizando si hace falta halgo adicional en el request como mas headers, pero no deberia ya que sin ASC/CAS funciona.

Voy a pensar en otra aproximación, pero por el momento si tienen mas noticias haganmelo saber.

[Eljeff13]

@dvalbuena1 yo llegue a la misma conclusión, es como si faltara algo, pero luego en algún momento el código lo hizo agendo, lo que pienso es que podríamos trabajar en la implementación de que no se loggee tantas veces si no que refresque la pagina, sin embargo si tienes una nueva visión sobre el problema házmelo saber, de hecho la taza de éxito es del 10%, por cada 10 falsos 1 es verdadero de hecho podria seguir aumentando, según las estimaciones que he hecho.

[jrojas-qventus]

Recuerden que la implementacion es en un lambda y que intentar refrescar significaria mas tiempo, mas consumo y mas recursos.

[jrojas-qventus]

De hecho estuve haciendo algunas pruebas y pense que si podria ser que otro usuario al mismo instante intento agendar la cita, pero no es asi. Y me di cuenta que al intentar agendarla con ASC/CAS siempre genera el problema. Se obtiene codigo 200 como respuesta pero voy a validar y nada. Ademas, valido nuevamente y la misma fecha aun esta disponible asi que significa que nadie la tomo. Incluso intento hacer el proceso manual desde la pagina usando la misma fecha y funciona sin problema.

Lo que me parece muy extraño es que simplemente añadiendo las siguientes lineas al request se presente ese error.

asc_data = {
"appointments[asc_appointment][facility_id]": ASC_ID,
"appointments[asc_appointment][date]": asc_date,
"appointments[asc_appointment][time]": asc_time
}

En el momento estoy analizando si hace falta halgo adicional en el request como mas headers, pero no deberia ya que sin ASC/CAS funciona.

Voy a pensar en otra aproximación, pero por el momento si tienen mas noticias haganmelo saber.

A mi personalmente he intentado reagendarla a mano, cuando sale el slot disponible y lleno todos los campos y le doy confirmar me sale una ventana que dice que la cita ya no esta disponible. Siento que por parte de la pagina de la embajada hay un error de sincronizacion y que se sigue mostrando la cita asi ya se haya tomado.

[Eljeff13]

Eso creo que si es cuando te roban la cita.

[Eljeff13]

@dvalbuena1 Has encontrado alguna solucion?

[jrojas-qventus]

Yo logre adelantar mi cita, pero despues de eso pense en otra alternativa para evitar el envio de mensaje sin confirmacion de cita. Pero puede aumentar los costos de la lambda ligeramente y su tiempo de uso.

La solucion seria:

1. al iniciar sesion guardar la fecha en una variable
2. hacer el proceso para agendar la cita via HTTP POST
3. Una vez hecho volver a la pagina de inicio y comparar si las fechas que aparecen de las citas son las mismas
4. Si son diferentes entonces mandar el mensaje al usuario.

[Eljeff13]

@jrojas-qventus lo hiciste con este método? Te enviaba falsos positivos?

[jrojas-qventus]

Lo hice como el repositorio te lo da originalmente, si, me enviaba falsos positivos y un dia me desperte y me llego al correo la confirmacion de Yatri diciendo que mi cita habia sido reagendada.

tiempo total de uso del lamda: aprox 1 mes y 10 dias

[Eljeff13]

Ejecución cada 10 min?