Skip to content

Conversation

Gpetrak
Copy link
Contributor

@Gpetrak Gpetrak commented Sep 9, 2025

This PR was created according to this issue: #13493

Checklist

Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

For all pull requests:

  • Confirm you have read the contribution guidelines
  • You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
  • Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

  • There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
  • The issue connected to the PR must have Labels and Milestone assigned
  • PR for bug fixes and small new features are presented as a single commit
  • PR title must be in the form "[Fixes #<issue_number>] Title of the PR"
  • New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented

Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

@Gpetrak Gpetrak added this to the 5.0.0 milestone Sep 9, 2025
@Gpetrak Gpetrak self-assigned this Sep 9, 2025
@cla-bot cla-bot bot added the cla-signed CLA Bot: community license agreement signed label Sep 9, 2025
@Gpetrak Gpetrak linked an issue Sep 9, 2025 that may be closed by this pull request
Copy link

codecov bot commented Sep 9, 2025

Codecov Report

❌ Patch coverage is 93.18182% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.79%. Comparing base (1292fd6) to head (7b10491).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #13494      +/-   ##
==========================================
+ Coverage   73.71%   73.79%   +0.08%     
==========================================
  Files         921      921              
  Lines       54192    54277      +85     
  Branches     6168     6180      +12     
==========================================
+ Hits        39945    40055     +110     
+ Misses      12644    12627      -17     
+ Partials     1603     1595       -8     
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Copy link
Contributor

@mattiagiupponi mattiagiupponi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please check the commetns

Copy link
Contributor

@mattiagiupponi mattiagiupponi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please check the comments

from geonode.resource.manager import resource_manager
from geonode.resource.models import ExecutionRequest
from geonode.upload.api.exceptions import ImportException
from geonode.upload.celery_tasks import ErrorBaseTaskClass, import_orchestrator
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the ErrorBaseTaskClass still needed?

from osgeo import ogr
from django_celery_results.models import TaskResult

from geonode.upload.handlers.gpkg.tasks import SingleMessageErrorHandler
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is SingleMessageErrorHandler still needed? if not we can remove it

Called when the task fails.
Updates the ExecutionRequest.tasks dict and delegates logging/error handling to evaluate_error.
"""
task_name = self.name
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way to keep this part in common in a private function of the Task? Since i see that is repeted, just the state of the set_task_status changes

task_name = self.name
execution_id = args[0]
layer_key = find_key_recursively(kwargs, "layer_key")

self.set_task_status(task_name, execution_id, layer_key, "FAILED")

"""
Set the task status for the on_success and on_failure celery methods
"""
_exec = orchestrator.get_execution_object(execution_id)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gpetrak as a note for the future, we should evaluate to have a cache for this function.

layer_names, _, _ = self.handler().import_resource(self.files, execution_id, **kwargs)

# Register the tasks_status with the created key alternates
orchestrator.register_task_status(execution_id, layer_names, task_name, status="RUNNING")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would suggest to keep this in a private function of the Datastore object. In case we need to make changes to the function at least will be in a single place

)

# We create the layer key through which the layer is stored in the tasks schema
kwargs["layer_key"] = create_layer_key(layer_name, str(execution_id)).lower()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is possible to keep the .lower() in the create_layer_key method instead of here? Or in some other cases should be kept as it is? having the .lower() in the method will keep consistency

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed CLA Bot: community license agreement signed enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Track importer's celery task results using ExecutionRequest model
2 participants