tile38-server parameter requirements

[huangpeizhi2018]

Could a command-line parameter similar to -l be added to the tile38-server service? If this parameter is configured, it indicates output json to avoid the problem that some encapsulated redis components cannot control the output format

[iwpnd]

I love the idea, because I’m jumping through hoops with pyle38 and tile38-ts to determine and set the output format for every connection. But this is something I still would have to do, simply because the client cannot just assume that the server always returns json - because not every server is also in client hands. Yet, with this option the client could at least skip a few steps, if OUTPUT returns JSON on first call when server has been started with „-l“.

[tidwall]

Makes sense to me. Maybe something like -o json or -o resp where resp is still the default?

[huangpeizhi2018]

:) -o json ，setup default output is json format.

[tidwall]

I added the new flag. Hope this helps y'all. :)

[huangpeizhi2018]

@tidwall , I started the Tile38 service with the -o flag, then used the go-redis/v9 library to connect to Tile38 and processed it using the SETCHAN command in the program, but an error occurred: ERRO[2025-10-09T09:39:39+08:00] SETCHAN command failed: redis: can't parse map reply: "$66".

[tidwall]

If you started with -o json then all responses will be RESP bulk strings that contain json. The "can't parse map reply" indicates that go-redis is expecting a RESP map, which starts with a '*' but got a bulk string instead (which starts with a '$'.

Can you show me an example of code for what you are doing?

[huangpeizhi2018]

@tidwall I use the Redis processing component of Bento(https://github.com/warpstreamlabs/bento) to operate on tile38, with the configuration file (geofencing_setchan.yaml) as follows:

input:
  generate:
    count: 1
    interval: "1s"
    mapping: |-
      root = {"latitude":23.414198, "longitude":113.20855, "name":"chan::1976120731355836418", "radius":100, "ttl":86400}

pipeline:
  processors:
     - branch:
        processors:
          - redis:
              url: redis://127.0.0.1:9851
              tls:
                enabled: false
              args_mapping: root = [ this.name, "EX", this.ttl, "WITHIN", "latest_gps", "FENCE", "DETECT", "enter,exit", "CIRCLE", this.latitude, this.longitude, this.radius ]
              command: SETCHAN
              retries: 3
              retry_period: 1s
          - catch:
              - mapping: |
                  root.error = error()
        result_map: |
          root.setchan.res = content().parse_json()

output:
  drop: {}
  processors:
    - log:
        level: INFO
        message: "setchan:: ${! this}"

This configuration file can be executed via command:

bento -c test/geofencing_setchan.yaml 

===========================================================

1. When the default output starts with resp： tile38-server -l json -o resp -d data Executing the setchan command is normal.

2. When the default output starts with json： tile38-server -l json -o json -d data

执行出错： ERRO SETCHAN command failed: redis: can't parse map reply: "$66" @service=bento label="" path=root.pipeline.processors.0.branch.processors.0 ERRO SETCHAN command failed: redis: can't parse map reply: "$66" @service=bento label="" path=root.pipeline.processors.0.branch.processors.0 ERRO SETCHAN command failed: redis: can't parse map reply: "$65" @service=bento label="" path=root.pipeline.processors.0.branch.processors.0 ERRO SETCHAN command failed: redis: can't parse map reply: "$66" @service=bento label="" path=root.pipeline.processors.0.branch.processors.0 INFO setchan:: {"latitude":23.414198,"longitude":113.20855,"name":"chan::1976120731355836418","radius":100,"setchan":{"res":{"error":"redis: can't parse map reply: "$66""}},"ttl":86400} @service=bento label="" path=root.output.processors.0

============================================================ Implementation of the Redis processor in Bento: https://github.com/warpstreamlabs/bento/blob/main/internal/impl/redis/processor.go

[tidwall]

It took a bit but I figured out what's happening.

When the -o json flag is used, every command response will be json. This is correct, but the go-redis client starts every connection with a "HELLO 3" and expects that the response is a map or an error. Because Tile38 is sending a json string the connection fails.

I added some logic which attempts to detect for the exact scenario and respond with a RESP error instead of JSON. This seems to clear up the problem with that client.

[huangpeizhi2018]

@tidwall Thank you very much, everything is working fine now.

[huangpeizhi2018]

@tidwall Just tested the bento input component redis_pubsub, also makes the go-redis/v9 library, when I used json output, I found that the subscription-triggered chan event are missing.

[tidwall]

The '-o json' flag changes all response to json strings, including the SUBSCRIBE command.

I made another small change adds to the previous client detection which ensures that the subscribe works as before for clients that appear to be redis libraries.

---

I'm not feeling too good about this new flag. Having to do client sniffing feels a little janky and I can't help but wonder if it might cause breaking issues for other clients. I worry we'll be playing whack-a-mole.

Good news is right now the flag is optional and it can't cause problems for those who don't use it. But perhaps it needs an explicit "experimental" label in the help menu.

[huangpeizhi2018]

I tested the event subscription feature, and it's back to normal now. As you suggested, I also think it's better to label it as experimental for now to avoid impacting core functionalities. I will continue to use the -o json option for a while., Thank you for your help.

[tidwall]

You’re welcome. I’m happy to hear it’s working now. I’ll continue to keep an eye on it. Thanks for the feedback.