Updated Redis Connections to use the correct credentials

[christophertubbs]

Actions taken previously were scattered between using a default redis password and redis hosts and ports for a defunct RQ configuration. That has been changed so that the elements connected to channels are connected to credentials for channels, elements connected to the runner are connected to the credentials for the runner, and elements connected to just redis by default are connected to the right credentials.

closes #649

[robertbartel]

I have a few minor comments, then one thing that I think needs to be fixed.

[robertbartel]

Not a huge deal, but is there a reason why this setting of request_id needs to be inside the loop?

[christophertubbs]

The redefinition of typing.Optional[str] here is just from copying and pasting, but the update of request_id is here to capture any possible redeclaration of request_id from within the message contents. The field is used for tracking async responses that may need to be acted upon, so if an optional request_id is passed through there, there'll be something on the other end listening for a response with it attached. Gotta make sure it has the most specific value.

[aaraney]

Should the request_id ever be allowed to change? Seems like that could be an invariant.

[christophertubbs]

In the message artifact or the variable in the function? Messages may come in looking something like:

        {
            "event": "search",
            "type": "send_message",
            "time": "6/18/2024, 12:31:09 PM",
            "data": [
                {
                    "identifier": 1,
                    "author": "christopher.tubbs",
                    "name": "Standard Test Evaluation",
                    "description": "The basic evaluation used for all testing purposes\n                        "
                },
                {
                    "identifier": 2,
                    "author": "christopher.tubbs",
                    "name": "Test Evaluation",
                    "description": "A sample evaluation to be run locally"
                }
            ],
            "request_id": "390l1uz74uf-n238l24383o"
        }

or they may come in with the format:

        {
            "event": "forward",
            "type": "send_message",
            "time": "6/18/2024, 12:31:09 PM",
            "data": {
                "event": "search",
                "type": "send_message",
                "time": "6/18/2024, 12:31:09 PM",
                "data": [
                    {
                        "identifier": 1,
                        "author": "christopher.tubbs",
                        "name": "Standard Test Evaluation",
                        "description": "The basic evaluation used for all testing purposes\n                        "
                    },
                    {
                        "identifier": 2,
                        "author": "christopher.tubbs",
                        "name": "Test Evaluation",
                        "description": "A sample evaluation to be run locally"
                    }
                ],
                "request_id": "390l1uz74uf-n238l24383o"
            },
            "request_id": "8sdfu57aOa5-8s5SF85a846"
        }

In both cases, the request_id of interest is "390l1uz74uf-n238l24383o". While the second example is far less common than the first, the inner most request_id value is what is of interest, not the outer.

Furthermore, that is the case with messages sent from the client that need to keep track of the responses to individual requests. Messages that do not need to keep track of an accompanying response may look something like:

        {
            "event": "connect",
            "type": "send_message",
            "time": "6/18/2024, 12:31:02 PM",
            "data": {
                "message": "Connection Accepted"
            },
            "request_id": null
        }

Messages originating from a client will most likely have a request_id on it, but it isn't required. It is just a tool that a client may take advantage of.

[robertbartel]

Similar to the above, why do this inside the loop?

[christophertubbs]

Same as above; the definition of deserialized_message is being drilled into, so any possible definition of request_id within needs to be captured.

[aaraney]

Building on @robertbartel's review, I had a few questions. Nothing major.

[aaraney]

Should the request_id ever be allowed to change? Seems like that could be an invariant.

[aaraney]

Looks good, thanks for making the changes!

Requested changes have been addressed.