Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Timeout querying against SurrealDB 2.0 #397

Open
faelau opened this issue Oct 7, 2024 · 6 comments
Open

Timeout querying against SurrealDB 2.0 #397

faelau opened this issue Oct 7, 2024 · 6 comments
Labels
bug Something isn't working datasource/SurrealDB

Comments

@faelau
Copy link

faelau commented Oct 7, 2024

The plugin is unable to issue queries against the two weeks ago released SurrealDB 2.0. Example query used for this bug report:

SELECT check_command,count(check_command) AS total FROM icinga WHERE ts > "2024-10-06T00:00:00Z"
 AND service_state == 'CRITICAL' GROUP BY check_command;

The queries are running in a timeout (nearly 50s):

<html><body><h1>504 Gateway Time-out</h1> The server didn't respond in time. </body></html>

The same query issued with the surreal CLI or Surrealist are returned very quickly and correct:

-------- Query 1 (44.724806ms) --------

[
	{
...
@adamyeats adamyeats moved this to Incoming in Partner Datasources Oct 15, 2024
@adamyeats adamyeats added datasource/SurrealDB bug Something isn't working and removed bug Something isn't working labels Oct 15, 2024
@adamyeats
Copy link
Collaborator

Thanks for reporting this @faelau ! Are you connecting the surreal CLI or Surrealist to the database using HTTP or WebSockets? The plugin uses the official Go library for SurrealDB, which, in turn, uses WebSockets to make a connection. It looks like you're getting the error back in HTTP format here, which indicates to me the issue could be one of the following:

  1. A networking issue (e.g. reverse proxy configuration) is causing WebSocket connections to time out
  2. An HTTP URL is used on the config page, which does not currently validate that only ws:// or wss:// protocol URLs are used at present. This is something we plan to address in future.

Are any of the following the case? If not, I can investigate further. Which version of SurrealDB 2.0 are you running? What types are the columns of the table that you're querying?

@faelau
Copy link
Author

faelau commented Oct 27, 2024

Hi,

sorry for the late response, was very sick.
I connecting the surreal CLI against the WebSocket, like that:

surreal sql --conn 'wss://surreal.example.com:443/rpc' --user root --pass abc123

It don't seem to be a network issue, I have tested that extensively. The connection URL in the config page is the same as used with surreal CLI.

The columns I'm querying are strings. The current version is 2.0.4:

2024-10-27T05:54:18.075451Z  INFO surreal::env: Running 2.0.4 for linux on x86_64

@adamyeats
Copy link
Collaborator

@faelau Thank you for confirming. Are you able to provide minimal set of steps to reliably reproduce this with a local version of SurrealDB 2.0? I am not able to reproduce this behaviour locally with SurrealDB v2.0.4.

@faelau
Copy link
Author

faelau commented Oct 28, 2024

Hi,

no problem! SurrealDB is installed like that with ArgoCD:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: surrealdb
  namespace: argocd
spec:
  project: default
  sources:
    - repoURL: 'https://helm.surrealdb.com'
      targetRevision: 0.3.4
      helm:
        valuesObject:
          image:
            tag: v2.0
          replicaCount: 3
          surrealdb:
            path: tikv://surrealdb-pd:2379
            initial_user: "root"
            initial_pass: "******"
          ingress:
            enabled: true
            className: traefik
            annotations:
              kubernetes.io/tls-acme: "true"
              cert-manager.io/cluster-issuer: letsencrypt
            defaultBackend: false
            hosts:
              - host: ******
                paths:
                  - path: /
                    pathType: Prefix
            tls:
              - hosts:
                - ******
                secretName: surreal-tls
      chart: surrealdb
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: surrealdb
  syncPolicy:
    automated: {}
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true

The database is created with a schema like that:

[{ events: {  }, fields: { check_command: 'DEFINE FIELD check_command ON icinga TYPE string PERMISSIONS FULL', duty: 'DEFINE FIELD duty ON icinga TYPE string PERMISSIONS FULL', hostname: 'DEFINE FIELD hostname ON icinga TYPE string PERMISSIONS FULL', service_name: 'DEFINE FIELD service_name ON icinga TYPE string PERMISSIONS FULL', service_output: 'DEFINE FIELD service_output ON icinga TYPE string PERMISSIONS FULL', service_state: 'DEFINE FIELD service_state ON icinga TYPE string PERMISSIONS FULL', ticket_nummer: 'DEFINE FIELD ticket_nummer ON icinga TYPE string PERMISSIONS FULL', ts: 'DEFINE FIELD ts ON icinga TYPE datetime PERMISSIONS FULL' }, indexes: {  }, lives: {  }, tables: {  } }]

Simple queries like that are working with both surreal and surrealdb-datasource:

SELECT * FROM icinga LIMIT 10;

This command is only working with surreal and producing a timeout with surrealdb-datasource:

SELECT check_command,count(check_command) AS total FROM icinga WHERE ts > "2024-10-06T00:00:00Z"
 AND service_state == 'CRITICAL' GROUP BY check_command;

@adamyeats
Copy link
Collaborator

@faelau Thank you very much for this! I'm able to get a clean reproduction of this issue locally. 🎉

It looks as if there is an issue with the WHERE ts > "2024-10-06T00:00:00Z" part of the SurrealQL clause. Removing this part of the query allows it to run as normal. Querying for the exact datetime of a record I have inserted to the table using = works correctly, but any comparisons with > or < causes a timeout. I've also tested this using the string type and the datetime type, which have the same effect.

It does look as if this might be an issue with the Go driver here, as I can get a consistent timeout from the driver with a minimal test case and the plugin side of the query seems to be working correctly. I will continue to investigate and update when I have more information.

@adamyeats adamyeats added the bug Something isn't working label Oct 29, 2024
@adamyeats adamyeats moved this from Waiting to Backlog in Partner Datasources Oct 29, 2024
@adamyeats adamyeats mentioned this issue Oct 29, 2024
Open
2 tasks
@adamyeats
Copy link
Collaborator

adamyeats commented Oct 29, 2024 •
edited
Loading

@faelau Unfortunately, it does indeed look like support for the v2.0 version of SurrealDB is still pending in the official Go driver. It looks like progress is being made on a new version, but there is currently not a timeline available for a new version of the driver to be released. Therefore, unfortunately, we are going to mark the datasource as compatible with v1.0 only for the time being.

I have opened a tracking issue here for you to follow, which I'll update when v2.0 support is ready. Unfortunately, we didn't catch this one as the README on the GitHub page for the driver doesn't seem to indicate that it is not v2.0 compatible, but it is actually documented in the driver docs on their website.

Thank you again for reporting your issue here! Apologies I've been unable to fix the issue for you at the moment, but I'll return to this as soon as I'm able to.

This was referenced Oct 29, 2024
Open
Merged
Merged
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees
No one assigned
Labels
bug Something isn't working datasource/SurrealDB
Projects
Partner Datasources
Status: Backlog
Milestone
No milestone
Development

No branches or pull requests
2 participants
@adamyeats @faelau