Log items that failed to import

It would certainly be useful to have an overview of items that failed to import. There is a Feeds log in the D7 version. I'm not sure why it was removed in the D8 version by twistor in this commit. I assume though because the Feeds log in the D7 version has some overlap with the core database log and some people reported that they don't want these logs in the database (see #1367044: Use syslog.module for feeds_log and/or an option to disable log).

Other log issues (D7):
#2364103: Feeds error log crashes when log messages are too long
#2827751: Log warning message when a parser suddenly returns empty results
#1037188: Log exceptions that are thrown when trying to fetch from a HTTP source.
#2815907: Add option to debug imported items

It would be good if we could come up with a design plan for bringing this feature back. How does the Migrate module handles this? Maybe we could use that as an idea.

This looks awesome!

Suggestions for improvements:

1. What would be awesome is if you could click an item in this list for details. You would then see the complete item with all its properties, something like this:
   

   {
     guid: 001,
     title: Question 1,
     description: The first question,
     roles: {
       editor,
       subscriber
     }
   }

   This way you could see for question 5 from your image example that it did not have a roles value.

2. The warning message above mentions the field machine name. It would be a good idea to add that information to details page.
3. The label 'Imported' is a little out of place. The item in question wasn't imported. Maybe 'Log time' would be better?
4. I'm wondering if the list should be limited to items that failed to import or if it should act more like a generic log. What if there were items that generated warnings on import, but got imported nevertheless? The log could then also contain information about at what times imports happened.
5. About people who may not want these logs in the database: it would be best to separate the implementation that creates the log message from the implementation that saves the log message. This way people that rather want these logs in a text file could swap out the log class. I think saving the logs should happen via an event subscriber. The created log message would then be the event.

In the past I have also been thinking about how the State class could be improved. This class does not collect all the error messages and keeps track of everything happening during the import. It would be great if somehow this class could be involved with this log process, rather than adding a new subsystem. I had been playing with some ideas for the State class for an other project that used a replacement for Feeds (as Feeds for D8 wasn't usable at the time). See attached.

Code snippet from the module:

/**
 * Processes the data.
 */
public function process() {
  $this->state = new State();

  foreach ($this->rows as $row) {
    // Process an item.
    $result = $this->processItem($row);
    // Keep track of what happened to the item.
    $this->state->report($result);
  }

  return $this;
}

1. +++ b/src/Feeds/Processor/EntityProcessorBase.php
   @@ -132,6 +132,7 @@ abstract class EntityProcessorBase extends ProcessorBase implements EntityProces
   +      \Drupal::moduleHandler()->invokeAll('unimported_record', [$entity, $feed]);
   
   +++ b/src/Form/DeleteMultiple.php
   @@ -124,6 +124,7 @@ class DeleteMultiple extends ConfirmFormBase {
   +      \Drupal::moduleHandler()->invokeAll('delete_multiple_log', [$this->feeds]);
   
   +++ b/src/Form/FeedDeleteForm.php
   @@ -38,7 +38,7 @@ class FeedDeleteForm extends ContentEntityConfirmFormBase {
   +    \Drupal::moduleHandler()->invokeAll('delete_log', [$this->entity->id()]);
   

   Feeds doesn't invoke any hooks at the moment. It would be better if this feature would be handled through events.

2. +++ b/src/Form/DeleteMultiple.php
   @@ -124,6 +124,7 @@ class DeleteMultiple extends ConfirmFormBase {
          $this->logger('feeds')->notice('Deleted @count feeds.', ['@count' => $count]);
   
   +++ b/src/Form/FeedDeleteForm.php
   @@ -38,7 +38,7 @@ class FeedDeleteForm extends ContentEntityConfirmFormBase {
        $this->logger('feeds')->notice('@type: deleted %title.', $args);
   

   I'm seeing a $this->logger here. Wouldn't it possible to hand over the task of logging unimported items to that object?

3. Maybe you want to post the feeds_log module as well, so others requesting the same feature can help forming it? It would also help in seeing where changes in Feeds are needed.
4. I've noticed that the Commerce project also contains a module for logging, called 'commerce_log'. Maybe a feeds_log module should be modelled after that? A feeds log entry would than be an entity, just as in commerce_log.

Closed #2981100: show failed imports on results page as a duplicate.

Changing title, so that the issue is hopefully found easier.

Feeds_log is exactly what we need in feeds. This or similar functionality should definitely become part of feeds. We just ran into the situation where 2 items were'nt imported but we couldn't find out why.

Plans in #9 look great!

@MegaChriz #9

Can you please suggest which event we can use here?
example : FeedsEvents::PARSE

Patch #8 now fails to apply. :(

Re-roll of #8 to current head 8.x-3.x. I haven't tested it.

May be enough to create new event and put it inside catch exception statement in EntityProcessorBase.php file.
Something like:

    catch (ValidationException $e) {
      $state->failed++;
      $state->setMessage($e->getFormattedMessage(), 'warning');

      $feed->dispatchEntityEvent(FeedsEvents::PROCESS_ENTITY_ERROR, $entity, $item, $e);

    }
    catch (\Exception $e) {
      $state->failed++;
      $state->setMessage($e->getMessage(), 'warning');

      $feed->dispatchEntityEvent(FeedsEvents::PROCESS_ENTITY_ERROR, $entity, $item, $e);
    }

so i can log also errors.
thanks

Can this feature be backport to D7?

Awesome work. Thanks guys.

Also, might be useful to mention this required module in the original post: https://www.drupal.org/project/feeds_log

I'm working on a detailed Feeds log system. The log system would cover the following information:

• Which source data was used for the import?
• Per imported item, how did the source item look like after parsing?
• Which entities got created, updated or deleted? And which did fail to import?

I'm doing this work for a client, so I hope the client continues to support this work so that I'm able to finish it.

Let me know your thoughts!

Description

Source data

The source data would be logged on the filesystem in a folder called:
private://feeds/logs/[import_id]/source/

Since fetching can technically happen multiple times per import, there could exist more than one logged source file per import.

Item data

The item data would be logged on the filesystem in a folder called:
private://feeds/logs/[import_id]/items/

User interface

On the feed entity, a new tab called "Logs" would appear. Clicking on this tab reveals all imports that ran, with the following information:

• Import start time
• Import finish time
• Number of log entries for this import
• Source files
• A link called "View entries" which would link to a page where all log entries for that import can be viewed.

On the page for a single import, a table consisting of the following information would be displayed:

Implementation

The State object would get a method called report(). This method would increase the counters for the operation that happened. For example "updated".

Reporting an operation

Code can report an operation in a form something like this:

$state->report(StateType::UPDATE, $message, [
  'feed' => FeedInterface $feed,
  'item' => ItemInterface $item,
  'entity' => EntityInterface $entity,
  'item_id' => $this->identifyEntity($entity), // See patch from #3063055: Allow parsers and event subscribers to mark an item as invalid.
]);

This would replace code like $state->updated++ and $state->setMessage().

Code on the State object would look something like this:

/**
 * Reports a processed item.
 *
 * @param string $code
 *   What happened to the imported item.
 */
public function report($code, $message, array $context = []) {
  $this->$code++;

  if (isset($context['feed'] && $context['feed'] instanceof FeedInterface)) {
    $feed = $context['feed'];
    unset($context['feed']);
    $this->eventDispatcher->dispatch(FeedsEvents::REPORT, new ReportEvent($feed, $code, $message, $context));
  }
}

Report event

A see you see above, a new event is dispatched there. Here is a draft of the ReportEvent class:

/**
 * Fired when the modification on an item gets reported.
 */
class ReportEvent extends EventBase {

  /**
   * The type of modification.
   *
   * @var string
   */
  protected $operation;

  /**
   * The reported message.
   *
   * @var string
   */
  protected $message;

  /**
   * The context data.
   *
   * @var array
   */
  protected $context;

  /**
   * Constructs a new ReportEvent object.
   *
   * @param \Drupal\feeds\FeedInterface $feed
   *   The feed.
   * @param string $operation
   *   What happened to the imported item.
   * @param string $message
   *   The reported message.
   * @param array $context
   *   The context data for the report event.
   */
  public function __construct(FeedInterface $feed, $operation, $message, array $context) {
    parent::__construct($feed);
    $this->operation = $operation;
    $this->message = $message;
    $this->context = $context;
  }

  /**
   * Returns what happened to an item.
   *
   * @return string
   *   The type of modification.
   */
  public function getOperation() {
    return $this->operation;
  }

  /**
   * Returns the reported message.
   *
   * @return string
   *   The reported message.
   */
  public function getMessage() {
    return $this->message;
  }

  /**
   * Returns the context data.
   *
   * @return array
   *   The context data. This can contain:
   *   - \Drupal\feeds\Feeds\Item\ItemInterface item
   *       In case when an entity was created or updated.
   *   - \Drupal\Core\Entity\EntityInterface entity
   *       The entity that was modified.
   *   - array|null item_id
   *       An array consisting of two elements where the first one is the
   *      indicator and the second the indicator type. Can be null.
   */
  public function getContext() {
    return $this->context;
  }

}

Feeds Log module

A new module called "feeds_log", added to the Feeds project, would subscribe to the ReportEvent and log the data it receives from it.

It would also subscribe to:

• InitEvent, to log the import start time.
• FetchEvent, to log the source file.
• ImportFinishedEvent, to log the import finish time.

The log collection for a single import would be stored in a content entity type called "feeds_import_log". On this entity type are stored:

• Import ID
• Feed ID
• Import start time
• Import end time
• The user under which the import is ran (can be different from who triggered it)
• Path to logged source files

Here is an initial implementation, so you can see where this is going. I've done some minimal testing and import reporting works at least if an import was succesful.

To do:

• Write fetched source data to a file.
• Write parsed items to files.
• Automated tests.
• Configuration options: for example, it would be useful to only enable logs for one specific feed type.
• Deleting old log entries.

Feedback on the direction this is going, is of course welcome.

I like the report function on the state object. It's like a Feeds specific version of Drupal log().

I worked with Feeds a lot in D7 and this would have helped me debug some problematic imports.

Having separate logs for the source and item is key. If a source isn't parsing the way you expect, having that source log is amazing.

Of course the items are also important to look at.

Haven't had a chance to test the patch but the UI you describe sounds great.

First of all, thanks for working on this feature request and thanks for this great module (Feeds).

I'm testing the patch from #20 and I know that it's not ready but I'm facing the error below on my existing drupal 9 setup. Is this expected?

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'item_id' in 'field list': INSERT INTO {feeds_import_log_entry} ("operation", "message", "timestamp", "item_id", "import_id", "feed_id", "entity_id", "entity_type_id", "entity_label", "variables") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => skipped [:db_insert_placeholder_1] => Skipped because the entity already exists. [:db_insert_placeholder_2] => 1603766676 [:db_insert_placeholder_3] => id: 14346 [:db_insert_placeholder_4] => 4 [:db_insert_placeholder_5] => 393 [:db_insert_placeholder_6] => [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => [:db_insert_placeholder_9] => a:0:{} )

These are the steps I've done:
1. Installed Feed log
2. Created a new feed of an existing feed type
3. Clicked on Save and Import
4. Error above was displayed.

@carolpettirossi
Great that you want to try it! If I look at my code I see I'm undecided on how to call the identifier for a new entity that failed to import and therefore has no entity ID. On one place in the code I call this "item_id", to designate the source item that failed to import, and on an other place I call this "entity_label", to hang a label on the entity that was in the process of getting created, but failed validation.

So if you replace all occurences of "item_id" with "entity_label" in the code, I think you will get past the error.

I hope my client gives me time again soon to continue this work. :)

@MegaChriz,

Just wanted to add here that I haven't had time yet to test what you suggested, but I'll try during this week or early next week.

Sorry about the delay. It took me longer than I expected in another task.

I had to do some adjustments in order to get the patch working:
- replaced all item_id by entity_label as per @MegaChriz suggestion on #23
- adjusted feeds_import_log_entry schema. entity_id can be null if the entity failed to import so I changed 'not null' to FALSE
- entity_id is INT, so I updated addLogEntry

With the adjustments above I could get it working for some simple scenarios

- Created
- Skipped because the entity already exists.
- Failed because it failed to validate

I'll ask my team help to validate it and add more feedback or patch updates here.

Small update to log the file path instead of 'abc'

@MegaChriz,

I'm wondering how can we log the source item. I can see this column in the report/log however the logItem function has not been implemented and I'm not sure what's your idea here.

I probably can help with the implementation just need some guidance in the right direction.

Thanks

@carolpettirossi
Many thanks for helping on this issue! In the D7 version of Feeds there already exists code to log a source item, so my idea was to try to port that code. See FeedsProcessor::exportObjectVars(). That method is called by FeedsProcessor::createLogEntry(), which is called when an exception occurs in FeedsProcessor::process().
https://git.drupalcode.org/project/feeds/-/blob/7.x-2.x/plugins/FeedsPro...

Thanks @MegaChriz.

I'll have a look as soon as I have more time allocated to this feature.

Re-rolling #26 cause it failed.

Great work.
Patch #29 works fine but is difficult to find where is the into source.

May be useful to add 2 new columns into feeds_import_log_entry:

The unique field value set into configuration of the feed.
The json encoded data of the source.

I think that with this information is easy debug the process and find error into source.

I've updated the issue summary.

Hopefully I'll have time again to continue this work soon.

patch no longer applies to latest feeds dev.

is there any development on this? i was never able to reach the log of which GUID's failed to import. this would help a lot to troubleshoot problems from the source and fix them there, especially for ongoing synchronizations. thanks in advance

I can confirm this patch isn't working anymore, is it still required?

It looks like the EntityProcessorInterface has changed.

Cheers Dan

My mistake, adding a patch that does apply.

#37 does not apply to alpha10, is it meant to be on: 8.x-3.x-dev?

ok, all sorted out. I was trying to figure out why my code to set the unique value wasn't working (#3232024: How to set Unique field?). On a whim i set force update and unchecked to authorize that user has access - and then everything worked. Figured it would have been great to have some sort of error msg to simply state i didnt have access - that brought me back to this post which i was familiar with from a year ago and realized the Feeds Log module never worked for me.

A little clean up:
- remove the old separate feeds_log module that i had enabled
- switch feeds to latest -dev
- apply patch from #37
- enable the log module which is now included with feeds

to test: set my force/authorize settings back as they were and re-import - and i now see log entire stating author of node didnt have access to update.

all good. Thank so much for this work.

Thanks for the updates, but note #37 is not ideal because it uses a different table name and different columns than the old standalone feeds_log module. Also I didn't really have a chance to review, but I wonder if a hook_uninstall might be warranted? Perhaps there is nothing to uninstall since the tables should be removed. Not sure but just in case it's needed...

Something like

/**
 * Implements hook_uninstall().
 * Delete all feeds log config entities.
 */
function feeds_log_uninstall() {
  foreach (\Drupal::entityTypeManager()->getStorage('feeds_log')->loadMultiple() as $machine_name => $entity) {
    $entity->delete();
  }
}

Secondly, I suppose because I have the language core module installed, I was getting an error importing a feed because there was no uuid column, so I added this to the .install to address the issue:

      'uuid' => array(
        'type' => 'varchar',
        'length' => 128,
        'not null' => TRUE,
        'default' => ''
      ),

In my case I had to uninstall the old feeds_log module, then re-install the new module in 37 to get this patch to work on the feeds dev version.

I really appreciate that you can click the "View entries" to see additional details on why something failed.

I wonder if, from a UI perspective, it might not make more sense though to add a separate tab called log-messages or something similar. I didn't find that link super intuitive until I clicked it.

Hi all, I just became maintainer of feeds_log module to create the Drupal 9 release.

The initial maintainer wrote on the module page at https://www.drupal.org/project/feeds_log:

Before install this module. please, apply this patch https://www.drupal.org/files/issues/2907721.patch. This patch used to invoke hook for feeds log.
Install this module one new tab will get add in feeds view i.e Unimported items.

As a first step, can we perhaps have these hooks added in feeds to allow to solve this in contrib cleanly? Of course we can rename them or whatever, but I guess adding hooks to allow contrib interaction won't do any harm?

But they should definitely be renamed to contain "feeds" ... "hook_delete_log" definitely is not cool ;D

Do you agree?

As of #42 I rerolled the patches from and renamed the hooks to work with 2.x of https://www.drupal.org/project/feeds_log

I changed my mind:
!THIS PATCH SHOULD NEVER BE COMMITTED!
Instead, I'd vote for a solution in feeds directly and deprecate the module once that's done! :)

Anyway, clean events for certain types of actions still wouldn't be wrong in feeds to allow contrib interaction. ;)

Contact me, if any changes in feeds_log are required in the meantime.

The Feeds log module has become a bit more usable:

• The fetched source file gets saved the log directory.
• Each parsed item gets logged to the log directory.
• There is a link to each logged file in the user interface. The links work at least when using the public file system. Probably requires some work when using the private file system.

Still requires:

• Tests;
• Configuration options;
• Ability to cleanup log files;
• Docblock documentation;
• Probably coding standard fixes.

Screenshots:

Overview of imports that ran

Overview of processed items from a single import

Hi MegaChriz,
great job :-)

Patch works fine!!

Why not separate failed items from success one?

May be useful to provide a filter in view entries log page to filter failed items.
Another options may be create a page with failed items only.

What do you thing?

Thank you in advance

@trickfun
Thanks for giving it a try! I already added the option to filter on failed items. Did you use the code from the issue fork "2907721-log-items-that"? It has more features than the patch from #37.

At a later stage I plan to add configuration for which operations to create log entries. So in that case you can configure it to only log failed items.

It is now possible to delete a single logged import in the UI.

Next step: add a button in the UI to delete all logged imports for a single feed.

@MegaChriz thanks for working on this! Do we have a timeline for the next dev release?

@webdrips
I hope my client allows to me finish this feature in the nearby future. After that, I'd like to test this Feeds Log module on a real website for a couple of weeks to maybe catch some bugs. When I find no serious issues, then I'll commit this to the dev version.

Today I've implemented a simple automatic cleanup of logs: logs are cleaned up after a week using cron. I also made viewing the logged files when using the private filesystem possible.

Next step is to add configuration options per feed type. It can be useful to only enable logs for certain feed types. Or to only log items that failed.

I implemented the option to enable/disable logging per feed type. How it works now is that when you haven't configured logging for a feed type yet, all gets logged for that feed type. Is that a good default? Because I was thinking that it would be nice that logging starts as soon as you enable the module. The alternative would be that when you enable the module, nothing gets logged initially. In that case you would need to update the configuration for each feed type.

The logging settings form for a feed type:

Let me know what you think should be the default:

1. Complete logging is active for all feed types upon enabling the Feeds Log module. Current behavior
2. Nothing gets logged when enabling the Feeds Log module. You need to activate logging for each feed type you want it for.

I'd vote for (1) as I'd see it as expected behavior. Otherwise, you won't even look for the module. And if things get too noisy, you can easily disable logging.

But I'm sure both would be fine, so don't make the decision too hard for you.

I agree with this default.
thank you

Uninstall bug fixed

I had waited with setting this to "Needs review" because there was a bug when you tried to uninstall the Feeds Log module: feed types could get deleted. That bug is fixed now in #3092823: Uninstalling Feeds Tamper will result into feeds type getting deleted.

Running the module for 6 days: some numbers

I've been running this log module on a client site for nearly a week now. It has already been helpful because once I could see why something wasn't imported. Some numbers about on how much space the logs take up:

• On the database it has not been that much: only 2MB for 571 imports. I did configure it though to not log items that were skipped, because that happens to the majority of items that get processed. Most items won't be different since the previous import.
• On the filesystem the logged sources and items do take up a lot of space. About 1GB in total. From this, the fetched sources take up the most of space. That makes sense, because I configured it to don't log source items that were skipped.

Cleaning up old logs

In a few days I can check how well cleaning up old logs will go. I've configured the log module to clean up logged imports that are older than a week (the default setting).

Issue: translated messages get logged

There is one known issue and that is that sometimes already translated messages get logged. When viewing the logs, these messages go through the translation layer again. I've been trying to fix that but I feel that opens an other can of worms, so I think it would be better to fix that in an other issue.

It would be great if others want to try the module too and see if you find any issues with it. I'll be monitoring the logs on that client site for at least some more weeks before I would commit this.

Sorry for my stupid question but how can i use this version with composer?
thank you

@MegaChriz can we get a patch to review? I believe I tried using the MR diff as a patch, and it broke the module at the time I tried it anyway.

@webdrips
Great that you want to give a try! I believe a patch should be completely the same as the plain diff: https://git.drupalcode.org/project/feeds/-/merge_requests/61.diff
Did you try to apply it to the latest dev? I guess it won't apply on Feeds 8.x-3.0-beta1.

@trickfun

1. Download the diff and save it in a folder of your project. For example in a folder called "patches".
2. Require the project "cweagans/composer-patches"
3. In your composer.json, in a section called "extra" and subsection "patches", define the patch to apply:
   

   "patches": {
     "drupal/feeds": {
       "Feeds Log module": "patches/61.diff"
     }
   }
   

I've been running it on a site for a few weeks now. I should recheck how the logs look like now, haven't checked them in a while. One thing I did realize is that not all messages that are logged in the "regular" log (like the database log, when using the dblog module) during an import can be found back in the log for the specific feed. For example: I noticed that messages for references that were not found don't appear in the feed log.

Thank you MegaChriz
patch works fine!!

one request more to complete your great job.
i need to import thousands of images with hundreds of error. images that are not there and so on...
what do you think to add "unique" field value in log table?

with this new column you can view directly the entity in error.

i think when importing commerce products or variations. views the sku in log table will be great.
thank you

@trickfun
In the column "entity" you can see which entity the import tried to create/update/clean, but it sounds like a good idea to have a column where you see the value for the target you marked as unique as well. You do can access that data if you configure it to log the source items.

Testing

I've been running the logs on a site for some time now. One thing I noticed today is that two logs from a few weeks ago were not cleaned up. Both of these were logs for imports that did not finish. I wonder what to do about these, because it is technically possible an import runs longer than a week, for example if you run cron only once a week.

I noticed that on the filesystem the logs take about 1.1GB of space. They took nearly 1GB of space when the logs were turned on for six days (see #53). I configured to keep the logs for 7 days, so that file size looks to be consistent.
The space the logs take in the database now is 2.2MB for 656 logged imports. That is still a pretty low amount of space.

Hi everyone,
Trying to update to beta1 but we seem to have this patch in prod that doesn't apply.
Does anyone have a patch that could apply cleanly to beta1?
Thanks!

@kyuubi
This is written on top of the dev version, might be a lot of work to make it apply to beta1 too since it is a large amount of code.

I have been planning to release beta2, just need to take some time to write proper release notes first. And I'm also actively using the dev version on some sites in the hope to detect possible regressions of recent changes. Nothing too disturbing so far, it's more like that I found some regressions lately that already have been there for multiple releases.
In other words, you could try this code in combination with the latest dev, looks like a better effort to me than trying to make it compatible with beta1.

Applying the merge request as a patch no longer works with the most recent dev branch on June 30: dev-3.x dfabf91.

I've rebased the code on the latest dev.

I can't apply patch to 6d17e51
thank you

Thanks MegaChriz!

We'll keep using the beta1 for now and might upgrade when this makes it in given everything works well currently.

Anyone can install patch with composer?
i can't.
diff doesn't work

thank you

Successfully applied the Merge Request in the beta2 version.

I have also tested the feature and it works great. Thanks all for the hard work. It's a really useful one.

I have found an error in case that the entity_label is longer than 255 characters. The database insert/update operations throw an error in that case.

I have refactored a little bit the code and added an extra sanitization code (https://git.drupalcode.org/issue/feeds-2907721/-/merge_requests/1)

@unstatu
Thanks for your contribution, I've added a check for the existance of $entry['item'] before trying to truncate it.

Also rebased the code on the latest dev. Attached a patch for beta2.

Hm, some tests are failing after rebasing the code. I'll look into it.

Great, tests are passing again! Back to "Needs review".

Hi,
I've been trying to apply the patch with composer and I'm getting the following error:

- Installing drupal/feeds (3.0.0-beta2): Extracting archive
- Applying patches for drupal/feeds
https://git.drupalcode.org/project/feeds/-/merge_requests/61.diff (#2907721 - Log items that failed to import)
Could not apply patch! Skipping. The error was: Cannot apply patch https://git.drupalcode.org/project/feeds/-/merge_requests/61.diff

But after running composer command I checked the feeds contrib module folder and I can see the diff applied, how is that possible that I'm getting error on the composer command?

Will appreciate any help or feedback on this.

Thanks

Why don't you use #68 patch ?
it is work.

Thanks @trickfun, #68 works fine for me now.

Cleanly applied to Beta2 and all is working well. Just saved me so much time tracking down a trivial error!!

I found a way to clean up old logs for imports that never finished! They get cleaned up after some time when a newer import for the same feed exist. This should be a good enough indicator that the older import is no longer running because it is discouraged to have two imports for the same feed active at the same time.

@trickfun

what do you think to add "unique" field value in log table?

I've added this feature now! You can test this if you apply the changes from the issue fork to the latest dev. The text does get truncated if it is longer than 255 chars.
This is how it looks like:

Feedback welcome!

Thank you MegaChriz.
It's work very well.

Now is clear what goes in error. :-)

I've made a few updates to the latest code:

• Security issue: fixed an access bypass on the log view. Added a database update function to fix that also for existing installs.
• Fixed a fatal error that occurred when disabling the view 'feeds_import_logs'.
• Code cleanups.

Thank you MegaChriz.
Great Job!!

con you provide the patch for beta 2?
thank you in advance

@trickfun
Here is patch against beta2. Not tested this one myself though. I hope to release beta3 in couple of weeks though or at least before December 14 when Drupal 10.0 gets released. So testing this in combination with the latest dev would be more valuable to me.

Sorry but i get this error.
Could not apply patch!

Oops, after applying the changes on top of beta2, I created a diff against dev instead of beta2.

New patch for beta2. :)

I finally merged the code! It will be included in the next Feeds release: 8.x-3.0-beta3. That release is planned to happen before December 14, when Drupal 10.0 gets released. That release will also be the first one compatible with Drupal 10.

#3132198: Clean queue tasks when unlocking a feed to prevent potential data loss is the only must have left for the next release.

I think that this does mean that https://www.drupal.org/project/feeds_log (maintained by @Anybody and others) now is obsolete as it has the same name as the module that is now part of Feeds.

Thank you MegaChriz
Great job!!