-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
editoast: add an endpoint to list infra objects #11032
base: dev
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
@@ -22,6 +22,11 @@ use crate::Retrieve; | |||||||||
|
||||||||||
crate::routes! { | ||||||||||
"/objects/{object_type}" => get_objects, | ||||||||||
"/objects/{object_type}/list" => list_objects, | ||||||||||
} | ||||||||||
|
||||||||||
editoast_common::schemas! { | ||||||||||
ListObjectsResponse, | ||||||||||
} | ||||||||||
|
||||||||||
#[derive(Debug, Error, EditoastError)] | ||||||||||
|
@@ -114,6 +119,47 @@ async fn get_objects( | |||||||||
Ok(Json(result)) | ||||||||||
} | ||||||||||
|
||||||||||
#[derive(serde::Serialize, utoipa::ToSchema)] | ||||||||||
struct ListObjectsResponse { | ||||||||||
ids: Vec<String>, | ||||||||||
} | ||||||||||
|
||||||||||
#[utoipa::path( | ||||||||||
get, path = "", | ||||||||||
tag = "infra", | ||||||||||
params(InfraIdParam, ObjectTypeParam), | ||||||||||
responses( | ||||||||||
(status = 200, description = "The list of objects", body = ListObjectsResponse), | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
or
Suggested change
directly There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Generally, it's a "good idea" to return json objects as a top level response... (To allow adding stuff later without making it a breaking change) But i could go either way, wdyt There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't mind an object at all, but in this case since the schema is only used at this one place better inline it |
||||||||||
(status = 404, description = "Infra ID invalid") | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
for consistency with the rest of the routes (that'll come with ViewErrors) |
||||||||||
) | ||||||||||
)] | ||||||||||
async fn list_objects( | ||||||||||
Path(infra_id_param): Path<InfraIdParam>, | ||||||||||
Path(object_type_param): Path<ObjectTypeParam>, | ||||||||||
Comment on lines
+137
to
+138
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||
State(db_pool): State<DbConnectionPoolV2>, | ||||||||||
Extension(auth): AuthenticationExt, | ||||||||||
) -> Result<Json<ListObjectsResponse>> { | ||||||||||
let authorized = auth | ||||||||||
.check_roles([BuiltinRole::InfraRead].into()) | ||||||||||
.await | ||||||||||
.map_err(AuthorizationError::AuthError)?; | ||||||||||
if !authorized { | ||||||||||
return Err(AuthorizationError::Forbidden.into()); | ||||||||||
} | ||||||||||
|
||||||||||
let infra_id = infra_id_param.infra_id; | ||||||||||
let infra = Infra::retrieve_or_fail(&mut db_pool.get().await?, infra_id, || { | ||||||||||
InfraApiError::NotFound { infra_id } | ||||||||||
}) | ||||||||||
.await?; | ||||||||||
|
||||||||||
let objects = infra | ||||||||||
.list_objects(&mut db_pool.get().await?, object_type_param.object_type) | ||||||||||
.await?; | ||||||||||
|
||||||||||
Ok(Json(ListObjectsResponse { ids: objects })) | ||||||||||
} | ||||||||||
|
||||||||||
#[cfg(test)] | ||||||||||
mod tests { | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. a test would be nice |
||||||||||
use axum::http::StatusCode; | ||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear to me why we need both a
get_objects
and alist_objects
. Couldn't we put the functionality directly in/objects/{object_type}
(if no ID is provided in the body, it defaults to returning all of them?). In any case, it'd be nice to add a description in the PR to explain why this PR.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we import the work schedules in OSRD, we look for their associated tracks, using GAIA. Sometimes, the track ids returned are in GAIA but not in the OSRD infrastructure. We don't want to keep these extra track ids.
To check this, we need an endpoint that returns track ids from the OSRD infrastructure. (Alternatively, the other solution would be to add another time-consuming track geometry verification step in the work schedule pipeline.)
Your suggestion would also be appropriate for this need
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(The problem with the actual endpoint is that it crashes when at least one track id in the given payload is not in the OSRD infrastructure)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re why not return everything with an empty payload... That's mainly because that felt like a potential mistake waiting to happen, and that you probably do not want to download all tracksections just to get a list of ids
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we only need the list of ids, i don't know if it would be possible to return this as default behavior of the existing endpoint ?