What causes 'rebuilding' status, and how to accelerate it?

Check out the description in API.txt

- **Rebuilding** (`FEATURES_REBUILDING`) This state is rarely seen and only
applies to **faux-exportables.** This state is shown when a
`FEATURES_REBUILDABLE` component is *currently* being synced to the database.
Usually this operation is very fast and short lived. However, if the operation
is interrupted (e.g. the server goes down) this state will be seen until the
rebuild locking semaphore is cleared.

You may want to read about the other states and how Features manages faux-exportables as well.

For anyone coming across this and looking for a way to fast track clearing the semaphore, The lock is stored as a variable named "features_semaphore". I just delete it directly from the database and truncate the cache table, but if you have a variable editor for development, use that instead.

I'm re-opening this just to get some input as well. now that D6 and higher has a locking api, it might make sense to use this instead of storing the data in the variables table. I'll take this on if its agreed that it sounds like a reasonable idea.

-Chris

For what it's worth, I had a feature that was stuck on "rebuilding". Then I cleared the cache and it was back in "default".

Another issue (for 7.x) that can cause this state continuously: changing the type of a field. Features can't make that work for obvious reasons. Arguably the UI should report that error.

So how would you handle this situation? Delete field > activate updated feature > revert?

Delete the field manually, yes. You'll lose data of course ..

I was having the same issue and running update.php did the trick for me.

Thanks for this thread.

I had this issue, and it turned out to be trying to change a text into a text_long field, so that each time I cleared the semaphore, it'd give me the same error and then get stuck.

error: FieldException: Cannot change an existing field's type. in field_update_field() (line 230 of /var/www/drupal/git-7/modules/field/field.crud.inc)

My feature is part of a complicated Drupal 7 site upgrade (from D5 in fact), and I suspect that this problem was caused by a change from my initial upgrade to a later attempt - during that time, the upgraded field type has been altered, some combination of a change of the orginal and maybe the D7 upgrade code.

Regardless of the origin of the problem, in this case all I had to do was to go in and edit the feature's field definition from type text_long back to text. Then getting rid of the semaphore variable worked to allow the feature to get installed and do it's work. The helpful thing I did was to throw a little debugging line just before the unhelpful error on line 230 above, so that I could see more details about the field it was trying to change type on.

I can confirm adixon's post. When trying to change a field's type, I'll get a similar error message (only slight line number difference).
FieldException: Cannot change an existing field's type. in field_update_field() (line 234 of /var/www/ecologic.eu/modules/field/field.crud.inc).

So, disabled and uninstalled the feature (via modules page), deleted the field in question and tried to re-install it. Custom content have not been altered and I get the above error message.

Next, I tried to delete the content type in question altogether but it remains in the content type list. I can even edit it but the delete link is no longer present. Disabling/un- and re-installing feature doesn't solve anything and I still get the above message.

Now, I am currently trying to clean up the mess of "ghost" content types.

Paul.b: both those problems (existing field change) and ghost content types have issue queue posts

further to #11 @hefox comment, here are links to the relevant issues:

existing field change - http://drupal.org/node/1201898

ghost content types - http://drupal.org/node/1055460

Seems to be evident in latest 7.x dev too, if you set a breakpoint on field.crud.inc around those lines (234) you should be able to see $prior_field and $field so you can see what it was changing from/to that was causing the issue

for me it was caused by the CCK migrate from D6 to D7 not lining up with my features definition.

so, kind of tricky one, not really bug or something to solve, just have to check your configs are all in the same line.

after that, you'll have to delete the locking semaphore to make it run again

mysql> delete from variable where name like "%features_sem%";

#4 worked for me. Had a persistent "Rebuilding" state. Cleared Cache and presto!

Go to devel/variable, select the variable named "features_semaphore" variable and click Delete. Clear the cache. Refresh the Feature.

Delete features_semaphore works like a charm :) But I'm not wise why I have this problem. Can't this caused any problem? I see in the comment above "Check out the description in API.txt" but can be someone more specific? I don't want to loose any data on production server in the future

This was happening to me when my feature had a field group in it and the updated feature no longer had a field group. I went into the content type and deleted the field group, then after reverting it finally worked.

I have the same question from #16

Can't this caused any problem?

I'm also concern of losing data. What is happening by removing the variable features_semaphore ?

For anyone that is trying to add this as part of a deployment process here is how to remove it programatically.
variable_del('features_semaphore');.

In my case...
This was causes to me because I was doing multiple features_revert on a deployment module. I remove the multiples feature_revert and only have one and this fixes my issues.

Since this issue is scoring fairly high when searching for [drupal features rebuilding], I thought it would be a good idea to mention here that this state may be a bit more common when your site is configured to not rebuild features on cache clear (setting "Rebuild features on cache clear" in the settings page for Features). Also worth mentioning is that the label "Rebuilding" will also be shown for the state FEATURES_REBUILDABLE.

I had similar issue. The cause was already existing fields in DB.

When I deleted them and run "revert" again - everything worked fine.

When it got stuck in "rebuilding" just run clear caches !

i tried clearing caches, that alone wasn't enough. had to delete the features_semaphore. so #3 worked for me, even after all these years. but your mileage may vary! sounds like various things can cause this problem. but try clearing cache first and if that doesn't work try deleting the features semaphore.

I recently ran into this issue and it turns out the issue in my case was a locked feature. Unlocking it resolved the issue.

The issue is still relevant. Deleting the semaphore did the trick.
Thanks.

We also had a similar case, when modifying block settings [might not be relevant, since it was the only thing modified].

Running cron didn't help, but a clear cache solved our issues.