I want to preface this with the fact that I am both relatively new to Rust and that this is my first time using shuttle so the issue is likely to be something dumb I missed. With that said. You can see the logs here https://pastebin.com/raw/gRLD8zZs, I cant really tell whats wrong from reading them. I can share the source code (not public yet) in case that helps later. I saw somewhere that you can use

Secrets.toml

and

Secrets.dev.toml

which I did use to change which sql schema file I use (the dev one clears the tables, other than that they are the same). I'm not sure if I should do something special to read in the contents of the file:

rs
  let schema = secret_store
    .get("SCHEMA")
    .expect("SCHEMA secret not found.");
  let schema = read_to_string(schema).expect("SCHEMA is read correctly.");

I feel like this should be fine (again, works fine locally and none of the expect error messages are appearing in the logs so idk) but including it anyway. I dont really have any other ideas as to what might be causing this. Im using Axum. In case this matters, my

dashboard

page appears to be empty still

Mmm.... you're probably running into the fact that Shuttle doesn't necessarily keep the exact file structure in the repo you're working on. At compile time the repo structure is intact, but not necessarily at runtime. Generally just the compiled assets are available, plus Known files like

Secrets.toml

. You may want to look into the static folder functionality (https://docs.shuttle.rs/resources/shuttle-static-folder) that Shuttle does know about for this kind of use case? Alternatively I'd suggest perhaps using compiler attributes like

#[cfg(debug_assertions)]

(memory's hazy on the exact syntax, but that's close I think?) to swap out the ones you want based on whether it's compiled locally in debug mode, or in release mode.

I see. Do you know if the stuff from Secrets.toml are available as normal environment variables during compile time? If thats the case I could also import the sql file with include_str!

I've not seen anything to that effect in documentation nor examples, so I would assume likely not.

Makes sense, thanks for the help! Curious as to why the file structure is different, any idea?

I'm sure it's probably just Shuttle trying to minimise how much storage space is really required for each container to run or something, but the shuttle folks could probably give a more comprehensive answer

That could also work yeah, looking into the static folder stuff right now as that probably doesnt need me to change too much

is that pastebin the full log? is anything further shown if you manually query

cargo shuttle logs <id>

with the last deployment id?

nope thats it

and you're sure your schema file is valid?

well its the same between both sql files except for the drop so probably?

sql
-- schema.dev.sql
DROP TABLE IF EXISTS metadata;
DROP TABLE IF EXISTS urls;

CREATE TABLE urls (
  id VARCHAR(6) PRIMARY KEY,
  url VARCHAR NOT NULL
);

CREATE TABLE metadata (
  id VARCHAR(6) REFERENCES urls(id),
  url VARCHAR NOT NULL,
  hits INT NOT NULL
);


-- schema.sql

CREATE TABLE urls (
  id VARCHAR(6) PRIMARY KEY,
  url VARCHAR NOT NULL
);

CREATE TABLE metadata (
  id VARCHAR(6) REFERENCES urls(id),
  url VARCHAR NOT NULL,
  hits INT NOT NULL
);

yeah, seems fine to me 🤔

ah, hm. I wonder if the

panic

is not getting caught by the logging infra, then

o

tracing might be a way to go... is

ShuttleAxum

a result type? it is for the serenity wrapper at least, so I do stuff like... https://github.com/vexx32/thread-tracker/blob/main/src/main.rs#L274C11-L279

that was indeed the issue 🗿

dashboard doesn't show anything atm, it's all CLI for now till they get some more frontend bits and pieces put in

Works fine now, thanks a lot!

awesome! np :3

One last thing, how do you usually interact with your db directly?

if I need to, I'll login with pgAdmin (probably any postgres-compatible db admin tool will work) -- once the service is started after a

cargo shuttle deploy

it'll give you a connection string for the DB that looks like this:

postgres://user-PROJECT-NAME:DB-PASSWORD@db.shuttle.rs:5432/db-PROJECT-NAME

take the

user-PROJECT-NAME

as the username, the

DB-PASSWORD

as the password, and give it to pgAdmin like this:

thanks :)

np ^^