Resolve route ambiguity for /tasks/activity endpoint

[Sujanadh]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧑‍💻 Refactor
• ✅ Test
• 🤖 Build or CI
• ❓ Other (please specify)

Related Issue

• Issue: Validated vs Mapped Task graph is not populated in infographics page #1923

{
  "errors": [
    {
      "loc": [
        "path",
        "task_id"
      ],
      "msg": "Input should be a valid integer, unable to parse string as an integer",
      "error": "Input should be a valid integer, unable to parse string as an integer['path', 'task_id']"
    }
  ]
}

Describe this PR

This PR resolves a routing issue in the /tasks/activity endpoint. A trailing slash (/) was added to the endpoint definition to ensure unambiguous route matching.

Previously, the /tasks/activity route conflicted with the dynamic route /tasks/{task_id}, causing the framework to misinterpret activity as a task_id, resulting in validation errors.

Screenshots

N/A

Alternative Approaches Considered

Did you attempt any other approaches that are not documented in code?

Review Guide

Notes for the reviewer. How to test this change?

Checklist before requesting a review

• 📖 Read the FMTM Contributing Guide: https://github.com/hotosm/fmtm/blob/main/CONTRIBUTING.md
• 📖 Read the HOT Code of Conduct: https://docs.hotosm.org/code-of-conduct
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[optional] What gif best describes this PR or how it makes you feel?

[spwoodcock]

One thing that is key to account for here is the route ordering in the xxx_routes.py file!

For example a /projects/{project_id} endpoint should be defined as late as possible,
then an endpoint like /projects/do-something defined above it.

The routes are resolved in order in the file, so if they were the other way around then FastAPI would try to load: /projects/do-something, but complain it can't find a project with id do-something as do-something would be passed as the {project_id}.

Something like this could be happening here 😄

[Sujanadh]

Yes, you are right. The actual issue is due to the ordering of endpoints. In addition to ordering, we need to define distinct endpoints with trailing slash '/' in every endpoint. What else would be the best approach to avoid this kind of issue? @spwoodcock Yes, we can maintain ordering and place endpoints with placeholders in the path following other endpoints.

[spwoodcock]

Yes, you are right. The actual issue is due to the ordering of endpoints. In addition to ordering, we need to define distinct endpoints with trailing slash '/' in every endpoint. What else would be the best approach to avoid this kind of issue? @spwoodcock Yes, we can maintain ordering and place endpoints with placeholders in the path following other endpoints.

We should be sure to not use a trailing slash for endpoints, but instead ensure the ordering is correct 👍

But note this is only ordering per router, so an alternative could be a different grouping of endpoints:

• We could better adhere to rest principals by putting nested tasks under the projects router. /projects/1/tasks/1
• Perhaps have an events router, using query params. /events?project_id=1&task_id=1
• Remove 'action' based endpoints, replacing them with a more generic version. For example on the organisations router, don't have a /approve endpoint, but instead a generic /status endpoint where we post the approved status.
• Loads of options here for improvement...

I digress 😅 In summary, for now let's just fix the ordering!