20240201 Weekly Development Meeting

[cgbosse]

• Time: 9:30 in Canary Islands (WET (UTC+0)).
• Time: 10:30 in Vaduz (CET (UTC+1)).

Location:
https://meeting.blockfinance-eco.li/NautilusCyberneeringWeeklyDevMeeting

Expected duration: 2 to 4 hours with breaks

Communicated attendants:

• CGarnham(@da2ce7) - x
• JCelano(@josecelano) - x
• CBosse(@cgbosse) - x
• MMelchor(@mario-nt) - x
• GByrne(@grmbyrn) - x
• MVanDijke(@WarmBeer) - x

---

Agenda:

1. Everyone will take their turn and:

• Go over his notes added as comments for the meeting which will have been added in advance to give an update of all the work done during the previous week indicating.
  • The issues worked on
  • The progress made on them
  • Other things done
• Inform of any faced challenges and request help if necessary to work on specific issues.
• Highlight the encountered difficulties, especially if there is a risk of them causing delays or affecting end product's quality.
• Communicate what will be the next week's tasks.
• List any new topics for further discussion in an additional Technical meeting that he noted for future discussion in comments to this discussion either before the meeting or after his turn so that they get considered.

During the meeting every team member will take their turns and follow this sequence.
The topics for further discussion will be noted in advance by each the team member and to the meetings agenda.

2. At the end of the meeting if there any new technical topics to be discussed further it will be decided to
   set another meeting date for the discussion of these or to hold the meeting hereafter.

Also the persons to be part of the meeting will be decided on so that the others will be free to continue their own work.

[mario-nt]

GUI

• Improve README file torrust/torrust-index-gui#457
• Update footer torrust/torrust-index-gui#401

Index

• User ID extractor for handlers that require an user id torrust/torrust-index#445

• refactor errors in extractor
• refactor handlers
• new custom error

• Static analysis (nightly) failing for PR checks torrust/torrust-index#449

New issues

• User ID extractor for handlers that require an user id torrust/torrust-index#445
• Optional user ID extractor for handlers that require an optional user id torrust/torrust-index#446
• Move authorization logic to new layer. torrust/torrust-index#448
• Static analysis (nightly) failing for PR checks torrust/torrust-index#449

Training & Research

• 401 vs 403 status codes
• RustRover HTTP requests client 101

Other

• Set up new PC

[josecelano]

Torrust Tracker

• Refactor: reorganize modules for console commands torrust/torrust-tracker#661

E2E test:

• E2E tests: Improve E2E test runner torrust/torrust-tracker#647
  • Detect panics in logs.
  • Ensure all services are running (HTTP, UDP and HealthCheck API) by reading logs (Started on ...).
  • Refactor:
    • Pass configuration with an env var instead of a temp file (TORRUST_CHECKER_CONFIG).
    • Extracted a nice wrapper for a tracker container: https://github.com/torrust/torrust-tracker/blob/develop/src/console/ci/e2e/tracker_container.rs

UDP Tracker client:

• UDP Tracker Client: add scrape request torrust/torrust-tracker#654
• Refactor: use JSON format instead of debug format. aquatic UDP responses don't support serialization. I had to add some new DTOs.
• See output: UDP Tracker Client: add scrape request torrust/torrust-tracker#654 (comment)

HTTP Tracker client:

• HTTP Tracker Client: add scrape request torrust/torrust-tracker#649
• See output: HTTP Tracker Client: add scrape request torrust/torrust-tracker#649 (comment)

Tracker Checker:

• Tracker Checker: pass configuration with env var torrust/torrust-tracker#656
• Tracker Checker: check HTTP trackers torrust/torrust-tracker#640
• Tracker Checker: check UDP trackers torrust/torrust-tracker#639 WIP: Draft PR.

Current output for the tracker checker:

Running checks for trackers ...
UDP trackers ...
✓ - Announce at 127.0.0.1:6969 is OK
✓ - Scrape at 127.0.0.1:6969 is OK
HTTP trackers ...
✓ - Announce at http://127.0.0.1:7070/ is OK
✓ - Scrape at http://127.0.0.1:7070/ is OK
Health checks ...
✓ - Health API at http://127.0.0.1:1313/health_check is OK

I'm working on the UDP tracker checks. You can run the checker with the local tracker with:

TORRUST_CHECKER_CONFIG='{
    "udp_trackers": ["127.0.0.1:6969"],
    "http_trackers": ["http://127.0.0.1:7070"],
    "health_checks": ["http://127.0.0.1:1313/health_check"]
}' cargo run --bin tracker_checker

Discussions:

1. The output for the tracker checker is text while the output for the HTTP and UDP clients is json. I'm planning to implement also JSON format for the checker. It's readable and better for automation.
2. See the general discussion about these new clients: Should we merge testing binaries into a single `Tracker Client`? torrust/torrust-tracker#660
3. I'm migrating all console commands to clap and anyhow.

Interesting things:

• I've tried the checker with other trackers from https://newtrackon.com/list and am getting some errors because some don't support non-mandatory fields in the responses. That means I have to change the clients to be more flexible with responses. I will open some new issues related to that, but we can implement them in the next milestone. For the time being, the checker works only with trackers that send the same fields as the Torrust Tracker.

[cgbosse]

Things I did this week:

• Created a brainstorming form for JC and me to go over next week to define better for the Designer what we need for the Torrust webpage.
• Started research on famous OS websites.
• Worked on some paperwork in preparation for my trip.
• Organized a lot of accounting docs.

Interesting links as to assignees and how to do PRs.:
https://opensource.creativecommons.org/contributing-code/pr-guidelines/

[mickvandijke]

Torrust Tracker

• Improved performance of the dashmap torrent repository implementation: Add a configurable memory limit to the torrent repository and implement dashmap [#567, #565] torrust/torrust-tracker#645
• Thought of and tried different implementations for fixing this issue and reopened the discussion about whether we actually need this: Implement a persistently ordered list of info hashes to be consumed by the index/API (for DashMap torrent repository) torrust/torrust-tracker#646