chore(logging): add additional logs for LTI launch flow

[arslanashraf7]

Description

There is not enough logging around the LTI feature when edX works as an LTI provider. This makes debugging any errors hard, and you have to run through the code to actually identify the failing reason.

This PR aims at improving this debugging and log information experience by adding additional logs around this feature.

Useful information to include:

• Which edX user roles will this change impact? "Developer", and "Operator".

Supporting information

Link to other information about the change, such as Jira issues, GitHub issues, or Discourse discussions.
Be sure to check they are publicly readable, or if not, repeat the information here.

Testing instructions

• You need to have an LTI setup locally
• Enable the FEATURES["ENABLE_LTI_PROVIDER"] = True in your settings/env
• Connect your setup with a testing LTI setup that can request LTI content from your edX instance
• Create specific scenaios by tweaking request data to see if the log statement logged the data properly

Please provide detailed step-by-step instructions for testing this change.

Deadline

"None" if there's no rush, or provide a specific date or event (and reason) if there is one.

Other information

Internal ticket: https://github.com/mitodl/hq/issues/6850
Include anything else that will help reviewers and consumers understand the change.

• Does this change depend on other changes elsewhere?
• Any special concerns or limitations? For example: deprecations, migrations, security, or accessibility.
• If your database migration can't be rolled back easily.

[openedx-webhooks]

Thanks for the pull request, @arslanashraf7!

This repository is currently maintained by @openedx/wg-maintenance-edx-platform.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[pdpinch]

This looks good to me, but I'm wondering if @xitij2000 could take a quick look since he's been involved with the LTI provider code.

[xitij2000]

Ill have a better look tomorrow, but i think only the relevant bits of the request object should be logged.

[xitij2000]

I think logging the request object is a bit overkill. I think it should be restricted to the relevant information.

[arslanashraf7]

The request part is basically for the URL that includes the course_id, block_id which will prove to be very useful while debugging issues with LTI. An example of this log currently looks like below:

2025-11-03 12:56:54,511 INFO 568 [edx.lti_provider] [user None] [ip 172.20.0.1] users.py:60 - LTI consumer requires existing user account for LTI user ID: <redacted_user_id> from request: <WSGIRequest: POST '/lti_provider/courses/course-v1:ORG+COURSE+1/block-v1:ORG+COURSE+1+type@vertical+block@ebe43296cab94c078b6fb3bb89f9863f'>

[xitij2000]

I think in that case you can log the course_id and block_id instead of the request. If you need the URL, you can log the URL.

[arslanashraf7]

@xitij2000 Sounds good, since the URL contains both the course_id and block_id, so I don't think we need to log them separately. I have updated the PR to just log request.path instead of the full request object. Let me know if this looks good to you.

[arslanashraf7]

@xitij2000 could you take another look at it? This is ready for your review, Thanks.

[xitij2000]

I think the log output should be updated to mention that it's outputting the request path and not the request object.

[xitij2000]

Just have one minor nit, which is to update the log message to mention that it's outputting the path and not the request.

[arslanashraf7]

Just have one minor nit, which is to update the log message to mention that it's outputting the path and not the request.

@xitij2000 thanks for the review. I've updated the messages to mention path in 1d72fec.

[mphilbrick211]

@arslanashraf7 @xitij2000 is this ready to merge?

[arslanashraf7]

@arslanashraf7 @xitij2000 is this ready to merge?

Yes.

@pdpinch I've squashed the commits and rebased the PR.

[pdpinch]

@arslanashraf7 can we backport this to ulmo?

[pdpinch]

lgtm

[arslanashraf7]

@arslanashraf7 can we backport this to ulmo?

Sure, The backport is #37707