- User Since
- Aug 24 2020, 6:20 AM (134 w, 6 d)
Fri, Mar 24
Makes sense! Thanks for clarifying and answering the questions!
Thu, Mar 23
I don't think doing input validation for SQL results is necessary – the any is fine here. It would probably have been more clear how / why you're using any if these utility functions were introduced in the same diff where they are used.
Wed, Mar 22
Tue, Mar 21
How the pinning will be saved on client's side? Do we plan to have it included in a message info? If that's the case, do we plan to update all the message infos saved on all the clients?
Fri, Mar 17
Wed, Mar 15
Do we know how this diff corresponds to https://linear.app/comm/issue/ENG-3322/fix-stale-cache-error-for-olmwasm#comment-d1aabe3d? Maybe this will somehow improve the experience about the path's configuration?
Tue, Mar 14
Mon, Mar 13
Looks ok - it doesn't seem necessary to do a migration.
Thu, Mar 9
Have you checked if Redis and MariaDB work correctly after this change? For me this seems like we're closing the files those processes opened for themselves which may cause incorrect behavior of them.
Wed, Mar 8
Tue, Mar 7
We persist messageStore.messages and threadStore in SQLite on the native client, and it would probably make the most sense to store pinned_messages in the SQLite threads table instead of introducing a whole new table and set of “ops.” That would introduce inconsistency between the MariaDB and SQLite database… which isn’t the end of the world, but could be avoided if we stored pinned_messages in the threads table?
In which way does it affect the database on the keyserver side?
It's really hard for me to find some advantages of having denormalized pins column on the server. It will make any querying based on pins a lot harder than it should be.
Fri, Mar 3
Improve parsing and error handling
Thu, Mar 2
Haven't figured out how to send a request from host, but verifying that is the next step.
Not sure what you exactly mean, but docker-compose exposes the service port to host, so you should be able to simplyyarn run-feature-flags-service-in-sandbox # in a separate terminal curl "http://localhost:50055/features?platform=..." # etc
The issue was caused by a fact that I was using localhost instead of 0.0.0.0. When running the service locally, there's no difference. But when a service is run within a container, the localhost doesn't work properly.
Bind to 0.0.0.0
Tue, Feb 28
Mon, Feb 27
Update cargo dependency