fmeringdal/nettu-scheduler

A self-hosted calendar and scheduler server.

nettu-scheduler's Issues

Inconsistency in SDK methods

I just realized to delete a user, we need to pass ID but to delete a calendar we need to pass DeleteCalendarInput which contains one field for ID.

It's better to follow one pattern.

It can be there for all requests, delete/update/... and calendar/event/user/...

Project Status

Is this project still alive?

Are contributions still welcome i.e. would they be possibly merged?

Scalibility and Reminders

In the k8s era, it's easily possible to have several running instances of a service and load balance between them.
The problem with the current reminder system (start_job_schedulers) is that it will be executed per instance (AKA pods for k8s), so we will have some reminders, some load on database, some web hook calls and ....

The solution can be having a separate binary, that will be executed separately with a corn service (OS or k8s).

Log errors on query failure

For some of the queries, if the query fails (eg. db connection failure) it's not possible to track down the error. The code below is one example: https://github.com/fmeringdal/nettu-scheduler/blob/master/scheduler/crates/infra/src/repos/account/postgres.rs#L125

migration is broken because of sqlx compile time query checking

I was following the readme file and trying to set up the development server for the first time. I got postgres running in a docker container after running docker-compose -f integrations/docker-compose.yml up -d. However, the scheduler won't compile when I do cargo run. Here's an example of the compiler errors:

error: error returned from database: relation "user_integrations" does not exist
--> crates/infra/src/repos/user_integrations/postgres.rs:44:9
|
44 | / sqlx::query!(
45 | | r#"
46 | | INSERT INTO user_integrations(account_uid, user_uid, provider, refresh_token, access_token, access_token_expires_ts)
47 | | VALUES($1, $2, $3, $4, $5, $6)
... |
54 | | integration.access_token_expires_ts
55 | | )
| |_________^

Turns out, these errors were thrown by sqlx's compile time query checking feature, and it won't compile unless we have everything in the database set up. However, we can't run the migrations to set up the database unless the code compiles and runs.

One workaround is to run the .sql files manually before compiling the code for the first time. But that renders automated migration useless, right? Can we turn off the compile time query checking in the code to prevent the deadlock from happening?

thread 'main' panicked at 'To create default account'

Hi there, found this repo through an old HN thread and am very excited by it as it seems to have a lot of great features. Great work!

The instructions for cargo run works perfectly 👌 but unfortunately, I am hitting some issues when using the nettu-scheduler:latest image.

I've enabled RUST_BACKTRACE=full incase it is helpful in debugging.

docker run -p 5000:5000 -e RUST_BACKTRACE=full -e ACCOUNT_API_KEY="JOHN" -e DATABASE_URL="postgresql://postgres:postgres@localhost:5432/nettuscheduler" fmeringdal/nettu-scheduler:latest

thread 'main' panicked at 'To create default account: pool timed out while waiting for an open connection', /home/rust/crates/api/src/lib.rs:172:18
stack backtrace:
   0:     0x5615e1f970f0 - std::backtrace_rs::backtrace::libunwind::trace::ha5edb8ba5c6b7a6c
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x5615e1f970f0 - std::backtrace_rs::backtrace::trace_unsynchronized::h0de86d320a827db2
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x5615e1f970f0 - std::sys_common::backtrace::_print_fmt::h97b9ad6f0a1380ff
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x5615e1f970f0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h14be7eb08f97fe80
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x5615e1fbab8f - core::fmt::write::h2ca8877d3e0e52de
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/fmt/mod.rs:1094:17
   5:     0x5615e1f90ff5 - std::io::Write::write_fmt::h64f5987220b618f4
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/io/mod.rs:1584:15
   6:     0x5615e1f9922b - std::sys_common::backtrace::_print::h7f1a4097308f2e0a
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x5615e1f9922b - std::sys_common::backtrace::print::h1f799fc2ca7f5035
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x5615e1f9922b - std::panicking::default_hook::{{closure}}::hf38436e8a3ce1071
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:208:50
   9:     0x5615e1f98cfd - std::panicking::default_hook::he2f8f3fae11ed1dd
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:225:9
  10:     0x5615e1f9983d - std::panicking::rust_panic_with_hook::h79a18548bd90c7d4
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:591:17
  11:     0x5615e1f993d7 - std::panicking::begin_panic_handler::{{closure}}::h212a72cc08e25126
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:497:13
{"v":0,"name":"nettu_scheduler_server","msg":"[USECASE EXECUTED BY ACCOUNT - END]","level":30,"hostname":"c7062d1a04f1","pid":1,"time":"2021-08-17T00:20:29.116945900+00:00","target":"nettu_scheduler_api::shared::usecase","line":68,"file":"crates/api/src/shared/usecase.rs","usecase":"SyncEventReminders","elapsed_milliseconds":60024}
{"v":0,"name":"nettu_scheduler_server","msg":"[USECASE EXECUTED BY ACCOUNT - END]","level":30,"hostname":"c7062d1a04f1","pid":1,"time":"2021-08-17T00:20:29.117019500+00:00","target":"nettu_scheduler_api::shared::usecase","line":68,"file":"crates/api/src/shared/usecase.rs","usecase":"GetUpcomingReminders","elapsed_milliseconds":29023}
  12:     0x5615e1f9758c - std::sys_common::backtrace::__rust_end_short_backtrace::hbd6897dd42bc0fcd
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x5615e1f99339 - rust_begin_unwind
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:493:5
  14:     0x5615e160b4a1 - core::panicking::panic_fmt::h77ecd04e9b1dd84d
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/panicking.rs:92:14
  15:     0x5615e160b593 - core::result::unwrap_failed::hcbdf25d28ce8f0ca
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/result.rs:1355:5
  16:     0x5615e16af6bb - nettu_scheduler::main::{{closure}}::h8b52303dba30fd4d
  17:     0x5615e1662e90 - <tokio::task::local::RunUntil<T> as core::future::future::Future>::poll::hb7651b6179296dd1
  18:     0x5615e16aa94c - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::hd9c78b3724817a0e
  19:     0x5615e1660f69 - tokio::runtime::basic_scheduler::BasicScheduler<P>::block_on::h060d79147c4f7119
  20:     0x5615e162ef11 - tokio::runtime::context::enter::h1854e0d2ef3876fd
  21:     0x5615e167ea85 - tokio::runtime::handle::Handle::enter::h0fb8c9743be40152
  22:     0x5615e1695747 - nettu_scheduler::main::h5db2b16262521d9c
  23:     0x5615e16bb6c3 - std::sys_common::backtrace::__rust_begin_short_backtrace::heffc8041cb84f74e
  24:     0x5615e16bb6d9 - std::rt::lang_start::{{closure}}::h634ffa86d9b93813
  25:     0x5615e1f99d3a - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hc4354216bf39217c
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/core/src/ops/function.rs:259:13
  26:     0x5615e1f99d3a - std::panicking::try::do_call::hb68eb312780385cf
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:379:40
  27:     0x5615e1f99d3a - std::panicking::try::h22b8e08595060b8b
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panicking.rs:343:19
  28:     0x5615e1f99d3a - std::panic::catch_unwind::hc64f1a6a0e71b1fc
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/panic.rs:431:14
  29:     0x5615e1f99d3a - std::rt::lang_start_internal::h4461fc58637f04f8
                               at /rustc/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/rt.rs:34:21
  30:     0x5615e16957f2 - main
  31:     0x7f1bcf35b0b3 - __libc_start_main
  32:     0x5615e160bc1e - _start
  33:                0x0 - <unknown>
Panic in Arbiter thread.

Is this a known issue? (And apologies in advance in case this is user error 😉 )

Replace week_start integer with an enum

It's unknown what the number is, for example, what is 0?
It's better to replace it with an enum, with weekdays.

For example:

WeekDay::Sat
...

User Buckets

Hello,

I'm new to this web app. :)

Is it possible to have user buckets/groups?
I mean, I want to have some groups of users and make it possible for "User A" to create an event for other users in their group.
Sure, "group" can be a "meta" tag we already have in the app, but "User A" should not be able to see other users in other groups, in ANY case, should not have access at all.

README seems broken

Currently, README seems broken.
Like, the setup commands don't work, it's not visible how we can set up DB locally.
Also I think inmemory doesn't exist anymore.

Production-ready versioning + docker + migrations

Seems like:

• there is no git versioning (tagging)
• the existing docker is only for development
• there is no migration, only the dbinit.sql

We need to have a production-ready code here, with proper versioning, production-ready docker, and migration scripts.

Tokio 1.0

Migrate this project over to Tokio 1.0. This requires using beta version of actix web, which should be fine.

Namespace environment variables and collection names

Thanks for the cool project! Scheduling isn't a simple problem, I'm looking forward to digging into this project more.

I noticed in the server setup that the environment variables aren't namespaced and could potentially conflict with other app settings. It's probably a good idea to prepend NETTU_ to the environment variables.

Also, it's probably a good idea to add a configurable prefix to the mongo collection names. In my case, my primary application is also using Mongo as a store, I'd want to have all the of nettu bookings etc... share a db with my project so that it's easy to use in aggregation pipelines, etc... and directly available to the app for consumption.

I'll take a look into adding some mongoose models for NodeJS that can be used for the collections you're creating and contribute them to the project.

Thanks again!

Support PostgreSQL

Hey :)

How hard is it to integrate other databases, like pgsql?
I can also help with this, but first would like to know if the general structure is ready?
And also would like to know your opinion?

How to set baseUrl for `@nettu/sdk-scheduler`

Cannot find the source or documentation of https://www.npmjs.com/package/@nettu/sdk-scheduler. The intention is to run this on a separate server from the main app.

`metadata` storage is not safe

The current metadata storage is not safe.

Currently, key and value is _ separated and it's easily breakable if we have _ in the key.
My suggestion is to use JSONB for the DB type and use serde to (de)serialize it.

Possibility to get_user_freebusy via the Rust SDK

Possibility to get user freebusy via the Rust SDK.