Sure @Mhmohona sorry, I shouldn't do that first, sorry for that... I will submit the work first

Hello @ParasharSarthak, I have completed local setup using Docker and have worked for an initial PR for the part structured, rotating file-based logging.
Implemented it with these details

• Added a new logging_config.py module with a RotatingFileHandler (10MB max, 5 backups)
• Updated app.py to call setup_logging(app) for Flask/Gunicorn logging
• Updated celeryWorker.py to call setup_logging() for consistent Celery task logging
• Mounted host ./logs/ to /app/logs/ in docker-compose.yml for log persistence across restarts

I'm ready to proceed with the next parts once you've had a chance to review.

Hi @ParasharSarthak I've completed the error handling and logging microtask.

What I fixed:

The current code has a lot of bare except: blocks that hide errors. I replaced them with proper exception handling and added structured logging.

What's in the patch:

• exceptions.py - 10 custom exception types (ValidationError, WikiAPIError, FileOperationError, etc.) so we actually know what failed instead of generic errors

• logging_config.py - Three log files with rotation (general, error-only, and JSON format). No more filling up disk space. Logs include context like which route/function failed.

• error_handlers.py - Standardized JSON error responses. Frontend can actually parse these consistently now.

• Celery task improvements - Added retry logic with exponential backoff, proper logging at each step, and CSRF token handling

• Example files - Shows how to update existing routes, utils, and tasks with the new error handling

• IMPLEMENTATION_GUIDE.md - Complete docs on how to integrate everything

It fully tested by myself pls check...

Should make debugging way easier and stop hiding failures. The IMPLEMENTATION_GUIDE has step-by-step integration instructions.

Pls review in free time @ParasharSarthak

Hi @Sukuna0007Abhi @Anirudh23090 @Mhmohona

Thank you all for the interest and the effort shown for this microtask. We really appreciate the enthusiasm and initiative.

Just to clarify, this task is part of Google Summer of Code 2026, and contributions for GSoC-related tasks are allowed only during the officially defined program timeline. Work on these tasks should not be started, claimed, self-assigned before the permitted phase.

For reference, the official GSoC 2026 program details and timeline are available here:
https://summerofcode.withgoogle.com/programs/2026

Any work done before the allowed contribution period cannot be considered for evaluation or merged as part of GSoC. We request everyone to please wait for the official contribution window and follow the process defined by the program. This helps ensure fairness and equal opportunity for all contributors.

We truly value your interest and look forward to your contributions during the appropriate phase.

Thank you for your understanding and cooperation.

Hi @LGoto,

Some contributors have started working on microtasks before the official contribution period began, and a few of them have also created changes.

Could you please let me know what the correct next steps should be? Should these changes be declined, or should they be kept aside and reconsidered during the official timeline? Also, does starting work early affect their eligibility to contribute in this project.

@LGoto can you answer to the above comment, also I think it is fine if we start before the contributing period but still please clarify it.

Hi @ParasharSarthak starting work early does not affect eligibility but we encourage everyone to wait until the official contribution period in order to be fair to all potential applicants and to avoid overwhelming mentors. It's up to you if you want to decline any changes now or wait to review them later.

I see you have already pointed folks to the timeline https://developers.google.com/open-source/gsoc/timeline
Feb 19 - Mar 15 is a time to discuss application ideas before the contribution period, which begins on Mar 16.

CC @Anirudh23090

@Anirudh23090 Please note that the contribution period does not start until March 16. Please wait until that date to submit work on tasks. You can continue to prepare and discuss ideas but @ParasharSarthak and team may still be preparing the project during this time.

Hi @ParasharSarthak, for this task I want to discuss how I plan to implement the task and the work I have done.
I have worked on:

• Custom Exceptions: Created exceptions.py with specific error classes like MediaWikiAPIError, UploadError, and ValidationError (inheriting from a base AppError).
• Structured Rotating File-Based Logging: Added logging_config.py to set up a RotatingFileHandler for both the Flask app and Celery workers, so logs are saved to a file without growing too large.
• Removed Broad Exceptions: Updated tasks.py and utils.py to catch specific errors (like requests.exceptions.RequestException) instead of using bare except Exception: blocks, which were hiding the real errors.

How I plan to implement the remaining parts:

1. Standardizing API Responses in app.py: Routes like /api/upload use local try-except blocks and manually return jsonify({"success": False, "errors":[str(e)]}). This creates duplicate code and inconsistent error formats. I will use Flask's @app.errorhandler(AppError) to catch all our custom errors globally. This will automatically format every error into a standard JSON response with the correct HTTP status code and error type, keeping the route code clean.
2. Handling Async Task Errors: In app.py, the /api/task_status/<task_id> route just returns str(task.result) when a task fails. This only gives a basic string instead of useful details. Since tasks.py now raises TaskError, I will update the status route to extract the actual error type and message from the serialized task.result. This way, the React frontend will receive proper JSON error details (e.g., whether it failed due to a timeout or bad credentials).

Please let me know if you have any feedback on this approach, I will create a PR for the changes accordingly after 16th March